Slashdot Mirror
Making Money With Open Code, APIs, And Docs?
"We've looked at the common model right now which is to sell support and give the code away on a CD for lots-o-money like a record label does. But our product doesn't work with that model very well. Our product is not many megabytes, so a CD to move bits isn't really justified. It's also fully documented in HTML, with man pages and HTML for the API, so a dead-tree manual is not needed at all. We're also doing development in a CMM-3+ environment, so there is no need for someone to buy support unless we purposely start adding "features" (i.e. bugs) or make it so complex no one can use it without calling us on the phone. That's just not an acceptable option since our product needs to operate in a five-9's environment, where if it doesn't work right it's never even allowed in the building.
We realize that if we do keep the source closed, but open the API or docs, someone will clone it because they don't want to pay for our work. Even with the typical no-quality clone, this makes the product life too short and the market too small to justify the large development costs.
Since the above model doesn't work for us, the only other way to make money (other then a sweet stock market scam) is to have a pile of patents. This is definitely not the way we want to go since we would need five lawyers for every geek in the company, and we all know software patents are all bogus since everything was done by 1975.
So did we back ourselves into a corner where we have to move to closed source or patents? Or should we just give up and go back to the day job working for someone with a pile of patents and a closed everything that can pay us? There are alot of issues here, but the bottom line is the bottom line, we have bills to pay, and if we can't pay them we'll go back to doing something else.
- frustrated."
How about giving the stuff away and charging for any future customisations a particular customer needs?
Rob.
At the end of the day, i'd guess, your company is in business to make money and I dont entirely see why you should be so keen to open source something if your livelyhoods depend on it.
Where open source fit in nicely is when a company has some internal software that they use and isn't central to their line of business. This way they can return something to the community and other people can help them sort out bugs.
Obviously open sourcing some of your products can help promote other products, but this essentially only works for large companies who aren't dependant on one core product.
If you have developed a package which is truly unique then you could potentially make a lot of money off it, and I think that's only fair. But unless opensource fits in well with your business proposal then there's no real reason to use it (apart from that warm fuzzy feeling inside)
Ok having stuck my head up and i'm going to hide before someone shoots it off :)
As a consultant that has worked in the industry for some years now, I can say that your situation is not unique and all, and that there are quite a few companies in the same boat as you.
Whilst excersing my new-found elite Linux skills using my Corel Linux box at home I have found an essay by someone called Eric S Ramond called "The Cathedral in the Bazaar" about the values of open source vs. closed source. An interesting read, if a bit naive, but it misses out one important point - people need money to live, and if their job is programming, they need to make money from doing that.
Now the technical benefits of open source may be apparent, but the philosophical baggage that it brings with it means that do develop an open source product at work, you need to either a) generate revenue through secondary services such as support or b) be part of a large company that can support the monetary loss.
This seems to me to be an unfortunate side-effect of the GNU Public License, and it means that the smaller players in the commercial sector will be unable to move to the open source model for financial reasons. Maybe a new licensing scheme is needed?
---
Jon E. Erikson
Jon Erikson, IT guru
What benefit do you hope to get from opening it up?
Do you want it to be debugged by the (purely hypothetical) "millions of eyes" of open source coders out there? No, you've already said that if it doesn't work first time, it's fucked.
Do you want the open sourcies to be involved in developing it going forward, and extending the program? If so, then consider a restrictive licence which puts it in the public domain, but with limited rights. Anyone who really wants to be involved in extending your product will still want to be involved (if it's good); as for the rest, fuck 'em.
Or do you want the deep satisfying feeling of being "part of the free software community", and "knowing that you Get It About Open Source"? Then go ahead, open it all up. But realise that this will probably be a costly luxury.
Or indeed, have you not thought about this in any very great depth yet? In which case, now might be a good time to start.
Oh yeh, and whatever you choose, software patents are almost certainly not going to help.
-- the most controversial site on the Web
Giving the code away is a good move in many aspect, it is good for marketing, and it is going with the current bandwagon. If your product is not that hard to replicate though, then it isn't worth much anyway - there is nothing terribly unique about it. Patents can be used to resolve certain IP issues - and they should be used if the IP is new, original and non-obvious. Of course, being a software only solution, you can only get the patent in America, which limits the power of the patent. You could give a free license for all free software, to avoid being badmouthed about it, but software patents are not desirable, as you point out.
Make the product a solution. Corporate entities buy solutions - basically products that solve one particular thing very well. The support for a solution will be there, and you can make money from selling the product as a solution. Many companies will also like the fact that they get the source, not the majority of companies, as it will mean nothing to them, but some. These companies will like the power to amend small things in the codebase to meet their needs.
Otherwise, you are hitting the nail on the head. What incentive is their to write easy, good quality software when you are trying to make money from support? Luckily most computer users aren't that clued up, and will need support whatever the software or hardware(Moving the Mouse for Dummies! etc).
It just depends on the target audience for the product, which you haven't specified, so it makes it hard to assess your chances. I wish you luck.
Alladin sells the latest version of their Ghostscript postscript interpreter, but open-sources the older versions. Of course the feasibility of this depends on the nature of the software, but it's still a fairly 'nice' way of making money and open-sourcing.
If a potential customer of yours sees more value in reimplementing your stuff than buying it from you then you have priced yourself out of that particular market anyway. So the debate is moot.
As usual in business life, offer something of value to the customer he is willing to pay for. I work in a five-9s environment. This is the perfect place for high-end support contracts. Of course no 'we will help you on the phone if you happen to get us on a free line' type of support, but a 'yes sir, we will be on site within 30 minutes 7 days a week 24 hours a day and make it work again' type of support. Priced, of course, accordingly.
90 percent of the support contracts of this kind are cover-my-ass contracts anyway, but in a five-9s environment you practically have to have these.
f.
Now this is important, so I'm gonna repeat it twice, with increasing emphasis:
If the legal work is not finished, the project is not finished
If the legal work is not finished, the project is not finished
If the legal work is not finished, the project is not finished
You screwed up badly by your own admission, by not getting good legal staff incorporated into the development plan. Now you're trying to rescue the whole deal. All I can reccommend is, hire a lawyer. And don't try to cut corners, because you've clearly developed the whole thin in this lop-sided fashion.
-- the most controversial site on the Web
The above is a good comment. If you visit the GNU website then there is a page off there somewhere listing all (or many) of the other open source licenses. Find one that roughly fits the above model and change it to suit your needs.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
There are probably downsides to this model as well, and I'm sure someone will point them out here. One of the chief benefits of this model, which I have not mentioned, is that the organization that supports the software need not be the one that made it (although there would be benefit to having made it), encouraging competition for support. Case in point where this model succeeds: IBM's Global Support Branch.
Brief summary of the argument: our customers are not the people who buy toolkits and components, they're people who buy completed applications. But in order to deliver completed applications we need a toolkit to build on. If we try to keep our toolkit proprietary, it will fall behind competing toolkits (such as, e.g., Enhydra) because we don't have, inside the team, enough people to develop it and debug it fast enough.
We could adopt another toolkit (such as Enhydra) but if we do we become just another user of the toolkit, with little control over its direction and no particular reason for people who want things built with it to come to us. By being the core of an Open Source project we get potential for kudos, the ability to steer the project, and, hopefully, a wider user base for the toolkit contributing patches and extensions.
I'm old enough to remember when discussions on Slashdot were well informed.
Without knowing the specifics of your case (how small the market, etc), it's a bit difficult to give a detailed answer, but probably the most important thing to realise about software is the following.
In my experience, most companies who are putting software into a mission-critical situation would prefer to pay for their software than have it for free. And what they perceive they are getting for their money is not the software itself, but rather a committment from the seller that the software will be supported. Your software doesn't have to be unreliable in order to justify a support contract; nor does it have to be heavily burdened with various flavours of intellectual property rights in order to persuade companies to part with large wads of dosh in exchange for it.
My suggestion would be to not make a big deal of the software license terms. Put it under a GPL or BSD style license, or even in the public domain, but just don't make a selling point out of it. Those who are interested enough to care will ask and be happy with the answer.
Make it available for download on a website, since it will be too small to justify the pricey-CD thing, but dress it up a bit like an evaluation copy -- probably best done by making it say "THIS IS AN UNSUPPORTED EVALUATION COPY", but it depends on the specifics of the case. Remember: the suits want to buy your committment, not your software! Do have a CD, though: make it part of your support contract, just so they have something physical and professional-looking to put on a shelf. Heck, if it's a small market, you can customise it by changing the "unsupported" message to indicate their name and the fact that you are supporting them. Such a comforting reminder! :-)
The benefits of this approach are many. One is that you can skimp on lawyers. You'll still need them for your support contract terms, for example. [Reminder to those who aren't catching on: support contract does not mean unreliable software; indeed, the ideal case is where you sell a support contract and never have a call from the customer because the software just works all the time. You think they'd be unhappy with paying for that level of service?] The customer is also happy because they don't have to count licenses or install dongles or do other obnoxious things associated with restrictive licensing. You can review their support contract service level agreement at regular intervals based on their usage, however.
Once you've got some suits paying you for your support, you should then aim to delight them with your responsiveness to their questions. You might want to hire a suitably talented monkey to handle the trivial stuff, but always be available to address the concerns of those you are being paid to support. Most proprietary houses set such dreadful standards of support that they shouldn't be hard to outdo. So long as they feel you are always poised and ready to answer your email or phone calls, they'll be happy and keep forking out the support contract fees.
Of course, there's the other class of people: the ones that don't pay. They are your friends too. Anyone with a clue who is using your software and providing you with bug reports is an ally. Be responsive to people who aren't paying you but who are doing you a great service by reporting real bugs, or simply providing ongoing testing (particularly for new releases). People without a clue who can't get it to work can be foisted off on some "users" mailing list or newsgroup: nobody should expect Linus to help them install their kernel.
I could go on, but I think by now you can see the pattern that is emerging, and decide whether it is appropriate to your situation.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
Let me reiterate what you have:
Given these factors, I'd suggest you simply stay closed-source. You'll have a hard-enough time making money from this anyway, even then.
If your customers demand source, sell it to them, but don't give it away. If you feel you need to give back to the community, there might be other, better ways - how about sponsoring development of free software you use, for example?
To wit: the company I work for makes extensive use of MICO, Xalan, Xerces, and Apache. We're closed source, but we contribute fixes, fund MICO-MT development, and will soon sponsor standardization committee activities for XML-Apache. In the end, everyone's happy. Maybe that would work for you, too?
There is a way to make money off GPL'd code, and it's been used by at least one product already, FFTW. FFTW is a high-speed fast fourier transform library, "Fastest FFT in the West", and it is distributed under the GPL. This means that it is available to anyone that wants to use it in their own GPL products.
So, I'm working on a project that uses this fourier transform to calculate derivatives of shoreline for calculating boundaries. I need FFT code; I go looking, boss man says write your own. I do, preformance sucks, no suprise. This stuff is at least one order of magnitude faster! But, boss man doesn't want anything to do with that communist open source code business.
Hence the magic. The author of the code can put whatever liscence he wants on it - or as many liscence as he wants. In this case, if you want to use it in a closed source commercial project, you can get a liscence for $5000 smackers, which is what the company ponied up - of course, they still made (much) more than that back.
Thus, this allows the two worlds to live together - if you want to get support, etc etc, pay the big money for the commericialized version. Or get the free version, with no warranty, as outlined in big letters in the GPL.
kudos!
..don't panic
I mean, one of Troll Tech.
All you have to do is to release your software under two different license: one open, that benefit from the Open Source development model, and one closed, whose you sell license to those that want to create (or use) closed-source stuff. This way you can combine best of both worlds.
Note, however, that it's not possible if you use free software code that you don't own. You may need to workaround this by spliting your programs in different parts, to isolate those you don't own and this way always release them under their original license without putting the rest of your work under the same licensing term.
Support means also hot-line and warranties. The "commercial release" will include them in your offer, and the "free release" will just have a disclaimer. Some people wants warranties, even if you swear your program is bugfree. These people will buy your stuff. "Service" dosn't mean you have to obfuscate on-line manuals and add bugs, just that your customer can ease his mind by thinking if your program crash his data, he can sue you.
sigmentation fault
The product you sell could include the source code under a disclosed source licence (but a user would still need to pay your company to use the product). Furthermore, you could permit registered users of your product to develop modifications and send each other patch files, as long as you are permitted to put the patches in your future releases.
It depends on the project,
But basically two models immediatelly comes to mind. Sell the peace of mind aspect, garantee (Don't have a clue how to spell this and no time).
And the other possibility is the expertize, people are willing to pay because they trust the person that sell's or supports the project.
Again it all depends on the project and the market. Make a deal with another company that have a complementary project let them pay for the development or alternativelly sell bundles with your stuff included.
Eg. Development project sell a Redhat CD with your product included a nice smile and support for the whole set of product for 6 month with direct access to experts in the field. Keep a constant contact with your customers ad I promise you they will be hooked. Add to that the possibility that you can sell the installation and the training for the product (training is kewl because even if the product is very easy to use people will still pay for it.)
Suffice it to say it is possible to sell alsmost anytnhig related to the product. Just think of it as a service industry and your home free. Sell your time your services.
Cu
jacobus@firsttech.net
Imagine that it is. Then no one can use any compiler that does not give an explicit permission to copy compiled binaries in its license. Now check out any compiler license from Microsoft, Borland, or Sun. Is the permission there? Check out your Notepad and Word licenses too. Do they give you an explicit permission to copy text files that were processed with these tools? No? You're SOL.
--
Industrial space for lease in Flatlandia.
We could answer your questions better if we knew more about your software.
If you are aiming at a large enough market, it is quite possible to get the benefits of open source without giving up the benefits ($$$) of non-free software. Put the source on the CD, shrink wrap the box, and stick it on the shelf in all the chain stores. It'll sell same as any other commercial product. After all, source code's only useful to programers, and we're a very small slice of the pie.
Likewise, if your taget market is very narrow, what do you lose? Chances are you were only going to make a few hundred sales, and in most cases those would be from larger businesses. In this case, you go on a support model.
Will some unscrupulous bastard give it away online? Sure. That'll happen with or without you opening the source. But by opening the source you've developed a rapport with the Open Source community, with all the benefits therein.
The only place I can't see Open Source non-free software working is in the mid-sized markets, but those are rarely where you find big money anyways.
Neu
- Why not release it as open source, but as shareware, so that if people want to use it they can and it is up to their conscience to register and send you the $50 or whatever you feel is appropriate. Remember, though, the more you ask for, the less registrations you'll get.
- You could offer rebates for people who have registered and then send in bugfixes.
- Alternatively, release as open source, but only charge for commercial use (like MySQL - http://www.mysql.com), so again, it is up to the company's conscience to send you $100 or whatever you think a company will think it is worth. Non-commercial users don't have to pay, but will quite likely contribute bug fixes and improvements.
- You could have a stable, bug-free version, and a development version that the contributors will help iron the bugs out of.
- Combining these approaches further, you could charge for the stable version (maybe release as binary only?), but allow free use of the development version to encourage bugfixes.
Well, you may agree with some or all of the above, or even none of it. I am interested in what others think.J
Here are some rather obvious observations, though I seldom see much reference to them during the time I've been reading /.
;) -- and of course programmers who still live at home and are supported by their parents.
Seems to me that most OS code has been developed by coders who have been supported in whole or in part by universities, benevolent corporations (large enough that they can't keep track of what some of their employees are doing, perhaps
Because circumstances allow this code to be developed for "free" -- it seems right that it should be released (with source) for free.
Code developed in the marketplace -- where the software developer assumes all of the risks and costs of development should have some rewards. Developers should not have to ask for remuneration by dangling support, upgrades or plain old begging. Whether or not the source can or should be released to the end user depends on the application/cost etc.
In any case, why should programmers feel guilty about selling a good piece of code?
What about the "millions of eyes" benefit of Open Source? No question that a large number of programmers have helped turn Linux into a viable server platform (I think the jury is still out for widespread desktop use).
I submit that for some applications, software is best improved by setting up a feedback loop with millions of CUSTOMER eyes -- not PROGRAMMER eyes.
So, if your company can muster the resouces to sustain the development of its software, then setting up a feedback loop with customers to further development seems like a good strategy. Let your customers "direct" the development by providing feedback on the features and functionality they desire.
Depending on the product, opening up APIs or code (with some reasonable restrictions) may turn out to be a requested "feature" -- or not.
Is this sig nificant?
One word: DeCSS.
--
Industrial space for lease in Flatlandia.
I don't understand why developers who feel secure releasing binaries are always so anxious to accompany the binaries with source. The assumption seems to be, "If I ship the source, some nasty bootlegger will come along and copy my stuff." But obviously it is considerably easier, rather than copying the source and recompiling it, to simply copy the binaries, or even to make a perfect duplicate of the entire install CD.
Look at Microsoft; they do not copy protect their software. Technically speaking you can duplicate, for example, the Office 97 CD. Has Microsoft gone broke? Hardly! They're the richest software vendors on the planet, but the only thing that prevents them from going broke is the respect end-users have for the terms of the EULA, or their fear of liability should they get caught, or whatever.
If a simple EULA is good enough to make Microsoft as rich as they are, why isn't it good enough for you? Simply draw up a license that says "you, the end-user, are only allowed to install as many copies of [your product] as you have acquired paid licenses therefore" and put it on the sleeve of the disc with the binaries and source. Yes, it doesn't protect you from a determined bootlegger, but then neither does withholding the source code - that bootlegger will simply copy the binaries, which are all that ninety-nine percent of users want anyway. If you're still upset over the possibility of a handful of illegal copies, then the only realistic solution is to close your code and ship your product with a parallel port lock or something like that - and even that will probably be cracked by some warez d00ds somewhere.
Yours WDK - WKiernan@concentric.net
I'm too lazy to type Sun's license agreement, but apparently it seeks to regulate distribution of compiled binaries only if the binaries happen to use "Tools.h++". This makes perfect sense to me. Tools.h++ is a library distributed as source code (by Rogue Wave I think). Software that uses Tools.h++ is a derivative work of Tools.h++. Compilers have nothing to do with it.
Oh well. Apparently all those companies that release closed-source stuff for Linux don't have legal departments, or use some super-sikr1t non-GPLed compiler. And the whole *BSD family is screwed, too.
--
Industrial space for lease in Flatlandia.
Ways to make money:
Sell add-on modules to the basic package.
Sell interface programs (from your package to other software packages).
Sell pre-loaded database of industry-standard (non-copyrighted) data.
Sell pre-loaded database of specific (licensed) data.
Sell pre-loaded database/catalog of vendor-specific data with an agreement from the vendor paying you a comission on product sales due to your software. (Major opportunities here.)
Sell custom code modifications.
Sell installation and training.
Sell services (remote application/data hosting).
Sell the associated (and required) big-buck database package (i.e., be an Informix, or Oracle reseller).
Sell software upgrade contracts. (Send notice/cd-rom when software is updated.)
Sell software support contracts. (Dial-in and telephone.) Assumes basic package is limited or no support.
OK, that took less than five minutes to come up with.
Thing is, figure out which you can do for least up-front outlay. Then offer that product/service. If it costs you nearly nothing, you don't lose big if nobody wants to buy, and you still have an impressive product/services list. The fact that not everybody will buy a particular product/service does NOT mean that NOBODY will want it.
Add to your product list. Keep adding to it. Don't let people think that you are a "one-trick pony". There's a world of folk out there who only want (for example) general ledger and accounts payable but who will not buy unless your product sheet shows payroll also.
I spent over eight years learning these lessons. If the moron who owned the company had learned any of them, we'd have made big bucks. He didn't; we didn't.
Good luck.
Which is to say: a suit (dark grey, navy blue, or pinstripe), a shirt (white, windsor collar, or button-down for Yanks) and a tie (regimental, polkadot, or City silver). Black brogues and socks.
Pop quiz; where is the greatest concentration of suits and ties? Japan, that's where. The reconstruction of Japanese society after the war can be directly traced to their adoption of Christian dress codes. Meanwhile, the decline and fall of America, Britain and practically everywhere else into a moral cesspool of drugs, casual sex, guns, and liberalism can be traced to the 1960s decision to shun the tie.
I think of the open collar as a "gateway drug", leading on to harder substitutes. From the open collar, it is but a small step to being jacketless; thence to the round neck; then the (shudder) short sleeves and than (I can scarcely bring myself to say it) "Genoese cut trousers of Serge de Nimes"
You will note that your own Mr. Hitler, while often seen in competent (if ugly) German tailoring, could never get a really good four-in-hand not to stay in his tie (often resorting to vile swastika tie-pins). Indeed, at the first chance they got, the whole mouldy bunch of them trooped off to the Black Forest, collars flapping open like so many deaths' head flags! Lederhosen! And the Tyrolean hats were hardly bowlers. You were quite right to hate them on sartorial grounds alone.
Remember, (if I may be permitted to avoid the invocation of Godwin's Law as well), that history has shown us that those who begin by burning foundation garments will later burn people. And the necktie is a foundation garment. It is the foundation of honesty, morality and decency.
On a more practical note, a well-cut suit conceals a multitude of sins, from a too-much-Chinese-food-and-Mountain-Dew belly to a pair of too-much-Quake-and-not-enough-rowing sloping shoulders. Geeks and coders are precisely those who are most in need of them.
thank you.
-- the most controversial site on the Web
If this product is in anyway a central part of your business, I would wait. Open Source is a business model, and just like any other business model, it has its risks and advantages. Importantly, Open Source is still an unproven business model. It reminds me of the whole free craze on the internet. The business model there is that you give stuff for free, and advertisers pay you for it. However, it turns out that that really doesn't work, and companies that give stuff away (like bigger.net or other free ISPs) are dissapearing. OSS still hasn't proved that it is a viable business model. Major companies like RedHat are still not making money off it, even tough they are in a strategic position in their market. Because of these reasons, I suggest you treat it like any other business model. Weigh the benifits and the risks. If it sounds like you can't stomach the risks, then OSS is probably not appropriate. Of course, as they say, nothing risked, nothing gained, eh?
A deep unwavering belief is a sure sign you're missing something...
Firstly - the GPL is designed in such a way to guarantee that if you try to sell your software as a product, and are making good profit margins, that someone will undercut you, using your own work; it removes barriers to entry.
>>>>>>>>>>>>>
This is a very important point. Open Source is meant for the common good of software users. As such, it enables anyone to take a piece of work, and improve on it. However, this very fact makes it impractical for a business. Consider this. RedHat spends time gussying up Linux for the mass market. It spends actual money make these additions. However, if they release them under the GPL, a competitor can simply come, take their changes, add something little to it, and end up with a better product. This isn't seen much in Linux, because the product is essentially already developed. However, say I write an application. I GPL it and make money by selling technical support. A competitor can immediatly come and make some improvements, and sell the resulting product. He now has a better product, and thus gets the sales. However, he did very little to "create" his product. This doesn't happen in the closed-source world, because instead of just taking your code, your competitor actually has to do work to create a competing product. It takes a lot less work (read: money!) to make small improvements to a product than to create a better product.
A deep unwavering belief is a sure sign you're missing something...
Perhaps you could release it, and the code, but with a restrictive license that doesn't allow redistribution... for the time being.
:)
You could put something in the license, though, that says "in 2002, this license will be null and void, replaced by the GNU General Public License (see Appendix A)"
That way, people have a warm fuzzy that the product has a life even if _you_ choose to move on to other things, they get the source right up front if they need it, and it still looks like you "get it."
What do you think?
---
As someone has pointed out, it's too late to be thinking about this.
Why did you write a product, before thinking about what you were going to do with it. The best fit for Free Software is stuff which you do not intend to sell -- for example, you may have been contracted to produce a POS system for a retailer. Once you have fulfilled that contract, and got paid, *then* you are in a position to GPL the source (unless the contract forbids it).
If you "just wrote it" with no real use for it yourselves, then selling it, closed license, is probably the only way you'll make any money. The best Free Software products were written because the author needed the software to do their job: take Apache; writing software was not the author's job description -- running a tight Web server was. Writing Apache made their job easier; giving it away (and developing an Apache community) made their job easier still.
--
There are many reasons why I think the GPL is really not going to work for commercial applications. It doesn't mean Open Source won't work, but the GPL in its current form allows too many opportunities for a competitor to take your code, mainly because that's exactly what the GPL was designed to do. The main reason is that it takes very little effort for another company to simply add on to your product. Thus, they end up with a superior product, at the cost of almost no R&D. This not only stiffles the development of the product (whose going to develop it if the other company will just steal it?) it takes sales away from the creator because the other company now has more resources (after all he spent very little "developing" a product!) to go after marketing and offering higher quality support. Maybe better for the consumer, but businesses won't like it, and in the end, they're the ones making the choices of what licenses to use. A more closed license (like the SCL) makes a lot more sense for businesses. It retains many of the advantages of Open Source, in that a consumer can fix bugs in their programs, and development speeds up, but it prevents another company from simply taking your work and adding to it. In the end, however, I think that commercial Open Source applications will be mostly second-rate. Put down those torches and hear me out. From a business point of view, Open Source is mostly a marketing gimmick. It is something that attracts users to your software. Unless the company is run by individuals that genuinely want to help users (rare, those people tend to set up projects instead) then OSS will be used as such. Usually marketing gimmicks are reserved for second-rate software. I think it is agreed that closed source allows a company to make a bigger profit of a high demand product. However, if the product is in low demand (read: low quality) then it may just be a way for a second-rate company to get some market share. Of course, there are exceptions to this, for example in system software and when facing software that is an entrenched power, even though superior solutions exist (read: Office). However, most popular software tends to be the higher quality ones, and I really don't think OSS is much of an incentive for companies making high quality software. If you doubt this, take a look at the current graphics market. NVIDIA is currently the market leader. There is nothing keeping them there (no propriotary APIs like Glide) except the sheer power of its hardware. (And good marketing to boot.) Now, second tier companies (like 3DFx and ATI) sieze this opportunity be releasing specs/open source drivers. This is the principal of using Open Source as a marketing gimmick for a product. I seriously doubt that anybody in 3DFx-land really wants to make the computing world a better place, (the original revolutionaries in management were mostly replaced, as was the original CEO), they are simply trying to regain market-share. This concept seems like it will progress to other companies in the software market as a whole, and unfortuneatly, OSS may not catch on in exactly the way you thought.
A deep unwavering belief is a sure sign you're missing something...
After someone on USENET mentioned some version of gcc that was modified in a very specialized way, and sold for $5000, that got me thinking. Under the GPL (and many other open source licenses), you don't have to reveal source unless you distribute. If the price point is really, really high, the fact that you are giving the product away (after the sale) won't matter.
Think about it. Sure, people burn red-hat CDs and give them to their friends all the time. It's only a few bucks. Pizza money. What's a pizza among friends? OTOH, some business that payed $5000 for a system is not gonna just burn it and give it to a friend.
This obviously only works if the system you are selling is worth that kind of money. What you are describing sounds like a fairly specialized mission-critical business application--the niche for which I've anticipated that this business model for open source could be successful.
This model obviously fails for small, general purpose, consumer applications (drawing programs, spreadsheets, word processors and the like). Nobody will pay $5000 for that kind of stuff.
I have also toyed with the idea of anouncing that all my software will be Open Source. But it will cost you $200,000. Hey, Free Speach is what matters, not Free Beer, right? :)
As a salesman for your company, I'd approach customers and sell them a system which includes software that they will be allowed to modify and customize without legal restrictions. Sounds like a good product now, eh?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Oh wait...you probably are that AC. Must be pretty hard to troll without contradicting yourself, eh?
--
Industrial space for lease in Flatlandia.
I was looking at this same idea for a game I might be developing. The way I see it, is you can just open part of the source, like the Quake engines do. Quake keeps the main engine closed source, since that's where the major competitive technology is. Everything else that uses the engine is open sourced. This way you can hide your "money making" parts of your source and still allow users to edit some of it. It may not be fully open source but it's a proven option that has worked immensely.
Outdoor digital photography, mostly in New Engl
Look into the Troll Tech model. Depending on what your product is you may be able to sell it for profit while making it free and open source for those who honestly prefer this.
If your product is a software library that can be used as part of other products then do exactly what Troll Tech dose with the QPL license too.
If your product is a server that dishes out content over the web ( AKA Real Player ) You make provisions that people must pay you or fully allow wholesale copying of all the content they distribute.
There are other solutions for other situations the key thing is to make your software free for those dealing in free content and free software. If it is done that way while remaining open source there will never be enough incentive for competent people to produce a free ( bear and speech ) clone.
You see people who live by copyright will find it simpler and perhaps cheaper to pay your license fees. Meanwhile those who live by Free Software and Open content will have no need to clone your stuff once the original works OK and you accept patches.
For proof of this just read of on the QT history. Ohh.. and try not to have any GPL compatibility issues even if it means saying "Thou shalt not write GPL code with our software"
--= Isn't it surprising how badly I spell ?
However, they will become more and more knowledgeable with the software, especially from the user-side. This will extend codewise if they can get the source easily. There'll be situations where they want to fix stuff themselves, in order to meet deadlines and other things.
I don't quite agree. The time it takes to determine that a bug exists, locate the bug in the code, figure out what the fix should be, test the fix to make sure it works, test the fix again to make sure it didn't break anything else, then to implement the fix, is just too much for most people.
It's not that they aren't intelligent enough to read code and see the problem -- I can usually do that, and I'm not a professional programmer -- it's that it often requires a significant amount of time and mental energy to wrap your mind around a problem. I don't want to take *my* time fixing *your* code, even if it's something that I need done quickly. I have more important things (to me) to do. Instead, I would prefer to call you up, describe the problem, perhaps give a rough explanation of what I think the bug is, and then be able to say "Our service contract says you'll take care of this. When might I expect an updated version?"
I don't think that open sourcing would drive companies away, unless they had enough resources to dedicate people to understanding and maintaining the code in-house. In that case, they're not buying the product anyway, and wouldn't be interested in a service contract either. However, it may pull in some people who would like to know what's going on inside that box on their desk -- people like me who like to tinker around with the code, but don't want to have to rely on my own skills to get some jobs done.
kipli
--
Industrial space for lease in Flatlandia.
Any evidence to support your claim? Name names, cite cases.
--
Industrial space for lease in Flatlandia.
Childish tactic. He said that IF the data generated by gcc is covered by the GPL THEN YOUR data is screwed, because data that is generated by gcc is everywhere. You say "great, now you see that the data generated by gcc is covered by the GPL". Unimpressing. I've seen trolls that are orders of magnitude more consistent than you.
--
Industrial space for lease in Flatlandia.
d. To procrastinate at work.
--
Industrial space for lease in Flatlandia.
I don't believe being forced to wear something uncomfortable aids productivity at all. At least with me, being forced to do something, regardless what, destroys my productivity.
I see no problem letting people dress the way they want- as long as they get work done! Would you rather have an office of slightly agitated coders or happy, relaxed coders, assuming both groups get the same amount of work done? If someone isn't working, fire them. If they won't work without a suit, they won't magically be motivated to work with one.
Before you start complaining about our style of dress having such complete control over productivity, give us some facts. Prove to us you are right.
I seriously doubt that a particular style of dress is the "real reason that so many of these Internet startups have failed." It may have a slight effect, but I'm guessing there are other, more significant things that cause the failure of a company.
You are probably right that a suit conveys the idea that you are there to work, but the lack of one does not mean that you cannot work.
Not wearing suits does not mean "insisting on comfort over results." No one ever said the two can't coincide. No one ever said that this industry was full of lazy, irresponsible geeks, either. If it was, the internet would work as well as a Microsoft application, and all the cell phones, pagers, videoconferencing equipment, office computers, and other office equipment used by who the geeks call "suits" would be about 10 years behind what it is now. I'm not saying there aren't lazy, irresponsible geeks out there, they're just not the ones running the industry. And wearing a suit has never been proven to turn a lazy, irresponsible geek into a stress-free, higly productive worker.
1. The Million Eyes. If you compile it they will come. If you open source it they will come... and fix it. At least that's the plan. Naturally "sexy" products get more attention in this model.
2. PR. Ugly, but true, a big chunk of OSS's benefits come from the PR boost it gives. Sure the stock-frenzy has calmed down a lot in the last while, but investors and customers still think that those of us in the open source camp know something they don't. Gosh, they say, they're giving their stuff away as a business model... they obviously know something we don't... buy their stock/product.
If you need a dose of 1 or 2, open source is for you. If not, open source is still an option as long as it doesn't put you out of business (or if you were never in business in the first place).
So, let's look at both: Number one (million eyes) can be an advantage. If your clients are 5-9s systems (I hear they exist, but working in a system rated as "an 8, a 5 and two 9s" I have a hard time imagining it) a million eyes may be regarded as a bonus. However, if your software is highly priced (as 5-9 stuff tends to be) you may be shooting yourself in the foot. Keep in mind, however, people will pay for the package to appease their boss. Witness my network. We run 250 Mac clients off several Solaris boxen. We use ethershare (about $12k). Netatalk is free. Fortunately for Helios (makers of ethershare) our uberboss would have an aneurism if he thought our workflow was entrusted to "something we downloaded off the net". It's not even a support issue... 80% of support is available in German only. Zum tuffel! ich ein komputererror! The question is: do the number of customers who will pay for peer-reviewed software outweight those who will download it for free. Get out the ouija board.
Does OSS PR matter? The question here is, do you believe that putting the GPL stamp of approval on your company brochure will move it closer to the top of tbe in box on the customer's desk. The PR game is tricky because you have to account for positive and negative publicity. You can have a great product, but if it's not open then all certain reviewers will discuss is your license.... not your software. Open sourcing avoids this bad PR. The good PR is trickier. For some customers it has a strong positive effect. For others, none at all... and for some it's a Bad Thing. If my Dad was shopping for serious corporate software (and god forbid he may one day...) he would definitely be adversely effected by open source. Sure he knows almost nothing about computers, but the vast majority of corporate budget-holders don't either. FUD is reality.
The bottom line IM(sometimes)HO is that you need to poll your customer base. The question is not "do you want open source" but do your customers want open source?
2 1337 4 u!
Compiler output is not a derivative work of the compiler....
:-) The unofficial translator won. It's been a while since I read about this case so I can't recall the details, but the translator was someone easily recognized today. Perhaps William F. Buckeley...)
Then why do many embedded system compilers charge per-customer royalties? Why did (does?) Microsoft include restrictions on the use of its compiler, e.g., you couldn't use MS C to develop a competing operating system or compiler?
This is one of those questions that can only be definitively answered by case law, but as I understand copyright law there is absolutely no doubt that the output of a <b>compiler</b> (but not assembler) is copyrighted. That's because compilers involve a significant amount of creative expression - do you unroll or optimize code, color registers, eliminate dead code, perform keyhole optimization, etc.?
A standard analogy is that assemblers are akin to transliteration of text, while compilers are akin to translation of text. Unless your lawyers are incompetent, they'll assure you that translators *always* have a copyright on the translated text.
(Historical sidenote: sometimes the translator's rights can exceed the original authors! In the 30's someone published an honest translation of _Mein Kampf_ and Hitler sued to cease publication. For some odd reason he wanted English speakers to see only a gutted version of his ravings.
Even if we posit that all of this work is unworthy of protection, there's the pesky fact that compilers rarely stand alone. Even if *your* code is unencumbered, you're gonna link it to startup code, standard libraries, etc.
Finally, your argument seems to come down to the compiler company's lawyers writing licenses that benefit the consumer. This is an... interesting idea. In the real world I doubt any of these lawyers would lose sleep over the fact that, *oops*, they forgot to include that clause and the customer needs to send in a check to get a license to distribute their own product. The major customers will always negotiate their own license terms (instead of being forced to accept the offered one or get lost) and I'm sure *those* licenses included the right to redistributed derived work.
(P.S., any usable text editor or word processor should give you back exactly what you put into it, so copyright law is not an issue. However, if you print to a file look at it carefully - you'll probably find a copyright notice in generated PS, PDF, or any other format that allows comments.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The basic idea of mass-market busking is that you give stuff away and just ask for donations (and make it convenient for people to do so).
The theory behind it is that groups which pay more will have more buskers trying to please them and get their money, so there is a direct benefit for paying.
It makes the whole process open and honest. You can tell people "I want your money" because the only way you're going to get it is by making something they like well enough to pay for after having tried it. "I want your money" becomes equivalent to "I want to do something which benefits you", because you can't get their money by tricking them into paying for a bad product sight-unseen or slipping in bugs and making them pay for the fixes later.
Paying is effectively saying "I appreciate your work, and I want you to continue with it, but I'm also willing to make similar payments to others who do useful work for me". Instead of hearing about a great company going out of business and thinking "too bad, I wish they could have found some way to force us to pay them the money they needed, I guess they just had a bad revenue model" you can think "hmm, I value their services, how much am I willing to spend to keep them going?".
I think a lot more people will pay if it's okay for them to pay $20 or $5 or $0.50, instead of paying $50 or nothing. I think this article from the mushroom makes my point fairly well. And, of course, it makes sense to pay more than once, depending on how long you use the product.
It is efficient, because there are no middle-men involved. Product goes directly to customers, payment goes directly to producers. Forget advertising costs, the customers seek out worthwhile free stuff and tell their friends about it. No distributors, no salesmen, just programmers, artists, writers, and other creative people. It will probably only cost about a third, and in many cases less, to make and release products of the same quality.
And, of course, it allows you to open-source your product. The users will make it their business to pay only those people who are really responsible for the development, so anyone who puts a stupid little wrapper around your product might get a small amount of payment appropriate to his own effort, but generally won't manage to usurp the rewards for the bulk of the work.
Right now, there are two good services for buskware payments: e-gold and paypal. Paypal is extremely easy to use but only available to Americans; e-gold is less efficient, but internationally available (and, being a gold exchange rather than a dollar exchange, is more suitable for international trade). Both allow all accounts to both give and receive. They are compatible, because you can buy e-gold with paypal, and then send it out of the country, very simply.
Yes, it will probably take some time for everyone to come around, and get used to paying for some future benefit, rather than to access things they would otherwise be cut off from, but somebody's got to start it.
Now this is important, so I'm gonna repeat it twice with increasing emphasis:
You don't need to license software you sell.
You don't need to license software you sell.
You don't need to license software you sell.
If you own the copyright, and don't give out any licenses, only you can make copies. Copyright law allows certain uses by anyone who buys a copy of software: installing it, running it, and making a backup. Very simple. No need to involve vicious packs of lawyers who piss off your customers and chew your profit margin to bits.
The standard practice of shrink-wrap licences is both unnecessary and legally questionable. Go ask a lawyer and he'll tell you that you should pay him more, every time, as long as he thinks you can make the payments (here's a hint: they ain't in it for the satisfaction of helping their fellow man). That's why everyone ends up with license who asks a lawyer, not because it's in their interest to have one, but because it's in the lawyer's interest to tell you to pay him for one.
Study the damned law yourself! Trust lawyers to tell you how much you should spend on lawyers, and you'll end up watching them suck you dry. (definitely don't trust me to tell you what to do. go check it out yourself. I could be lying, but I'm only telling you things you can easily check yourself)
I believe that's only a valid model if the product is a library. Qt does fit the open source definition and can therefore be used for just about anything. But it can't be used for commercial software because its license prevents linking to it (which is NOT prohibited in the OSD).
If your product is a program and is open source, then you cannot prevent its free use in for profit applications.
Sorry, I don't buy that. Apache was a great free software success before Sun and IBM leapt aboard -- indeed, it was Apache's ubiquity that led IBM to go with Apache rather than continue developing their own proprietary http server.
Yes, Apache would lack some key functionality without IBM/Sun's input, but without them, someone else would have done it.
--
Shareware sets a price, often a ridiculously high one chosen on the premise that only a tiny percentage of users will pay ($50 for a simple utility with a nice interface is pretty typical; I don't know about you, but I rarely have $50 just kicking around to give away). If people are willing to pay a little, but not that much, you get nothing. If people are willing to pay more, you lose out on the extra they would offer. Also, most shareware in the past (and present) doesn't have a convenient way to pay.
I suspect that pretty much everyone who uses the software wouldn't care about parting with a quarter or fifty cents, and most would give several dollars for a product they use often. Wealthy individuals or companies would likely be willing to pay a lot to get special attention paid to their bug/wish lists (look, here's a wad of cash, there's more where that came from if you make these changes).
There's pretty much nothing to make people pay for any software. The risk of being caught and punished is virtually nonexistant. Copying is easy and cheap.
Those who pay do so because they believe that it would be wrong not to, ultimately because if everybody did it, the products wouldn't exist. I believe that if you give people more freedom and control in this process, they will respond appropriately, and protect their own interests.
The penalty for not paying (or paying too little) is: being ignored by the mass-market buskers when they choose what to make. Broad appeal isn't always necessary, appeal to a profitable market is.
Mass-market busking is not appropriate for non-reproducable products and services, for obvious reasons. Things like HTML text, computer programs, and recorded music are special products that have unlimited supply once created. The only influence the user needs is over what is produced, and they could gain this influence by rewarding (with donations) the behavior which benefits them, effectivly training the system to serve them.