Slashdot Mirror
Examining Some Open Source Myths
Neil Gunton writes "I wrote an article distilling some thoughts on Open Source myths. Perhaps unusually, these are not myths propogated by the anti-OSS crowd, but rather dogma that is more frequently spouted by OSS proponents. It is not intended as an anti-OSS argument, but really more as observations and reactions to specific things people say without really thinking about it, such as 'You shouldn't complain about it if you don't want to put effort into providing a fix', 'OSS lets you get under the hood to fix problems', 'All software should be free', 'Scratching the personal itch', etc."
Many of this guy's comments are very good. In many ways, the programing industry is being hit by a much more general sweep of what I call 'copyright depreciation'. The really huge piracy with games, music and movies at the moment is a symptom of copyright depreciation and so is programing. I think a key cultural change in this century will be the rise in the difficulty of the ability to make money off copyrighted works.
In the past, a company could assemble a team of programmers and pay them to write a program for you. Really, the only way you could assemble such a team was under this structure. With the invention of the internet such teams can be assembled on-line and can work in their spare time. Couple this with the ability to be able to duplicate en mass for effectively zero cost makes this form of development very effective.
In the end, the programmer has to get paid or they can't make a living off it. What we're seeing is the destruction of huge profit margins and the market force establishing the 'true' value of a programmer.
Simon
That's news to me. I always regarded Windows to be ahead until w2k, and then the Linux apps quickly got their shit together. Since, they are more or less equal. Now, there's another system that kicks both their asses, MacOS X. That is to say, it kicks Linux' ass, but afterwards, it comforts Linux and give gentle hints on how to improve (Safari -> KHTML (or whatever)).
1. "If you're not willing to help fix it then you shouldn't complain about it"
This is not exactly how I see it. If someone contributes to any OSS project or supports open source, then they are part of the whole movement as far as Im concerned, and they have every right to complain..
If, however, they are ignorant of OSS, and complain about a program they were given that is OSS, then they should be paying for stuff..until they are no longer in ignorance...
I have no problem with people using copyright to charge for their software - it seems to me both parties get something from the deal. But it has to happen in a free market, and in the free market the price of information has fallen and can't get up.
As Shirky says: The price of information has not only gone into free fall in the last few years, it is still in free fall now, it will continue to fall long before it hits bottom, and when it does whole categories of currently lucrative businesses will be either transfigured unrecognizably or completely wiped out, and there is nothing anyone can do about it.
Nor should we. Industrialization wiped out the weavers' guilds, most of the farming population and the horse-cart manufacturers - and we're better off for it. The winds of change are blowing again. Let's tear down the windbreaks and build windmills instead.
Any sufficiently advanced libertarian utopia is indistinguishable from government.
1. This one understates the real problem. SOME open source developers may just as well be writing shareware. Naming no names, but I know at least one mail package that's completely closed to third party modifications... and I've run into other programs where the developers are nearly as hostile to patches.
2. This one, however, is no myth. The vast majority of open source software is very approachable, easy to get into and fix things. I'm no "super programmer" but I've submitted patches that have gone into programs from AMANDA to THTTPD... hmmm, I guess I better see what I can do about Zeroconf, I'm a few letters from the end of the alphabet.
Anyway, not "getting under the hood" is a choice. It's not hard and lets you scratch *your* itch.
3. There are many many people in the OSS movement who have no objection to closed source software. I was at Usenix when someone asked McKusick what he thought about someone "stealing" the TCP code from BSD to put it in closed source software. His response... he welcomed it. It meant better software all round.
4. You're assuming, again, that there's some basic conflict between the two approaches. Combine them, you get better software than either... there's hardly any significant proprietary system out there that isn't using OSS components. Apple is the obvious example, but Microsoft uses a lot of OSS in NT... they're even shipping a package containing GCC these days.
5. "Scratching the personal itch". Proprietary software publishers do that too. They talk about being "technically led" or "market led", but the result is the same... if their "personal itch" makes their software less usable or less secure, the user loses. Integrate browser and the desktop? User loses! Abandon GUI guidelines in favor of the New Metal Look? User loses!
What keeps them in check is competition, not any "market driven vision". And the same thing keeps OSS authors honest... PLUS with OSS you have a chance of getting into the source and scratching your itch as well in a way proprietary software can't equal.
6. "More choice is always better". You don't want to choose? That's a choice as well... and one you get to make. There's lots of prepackaged OSS-based systems that have someone's idea of what the "best choice" is.
7. Conclusion: it's not so simple. There isn't any one "Open Source" world, like there isn't any one "Proprietary world". Some OSS models are better than others. Some proprietary systems are better than others. Some OSS advocates have not-so-hidden agendas that you can learn to avoid... but most of those "myths" are simply a matter of your choosing *not* to take advantage of what OSS can offer you.
Just one minor nit: If you distribute your binaries and source together, then there is no obligation on you to distribute source to any Tom, Dick, and Harry. They will have to either get the complete package from you or deal with someone who did. The clause 2/3 distribution only comes into play if you distribute the binaries without source.
While it is certainly true that the GPL provide a fairly effectively means to prevent prices from getting unrealistic, it does not prevent you from selling software. Imagine a company that build a piece of software. They then choose to distribute it under the GPL, set up websites/ftp/mailinglists etc., demand a small fee for the download, make sure that paying customers allways get source, and make upgrades easy and frequent (and worhtwhile).
To "rip off" (as in fork the project and become the "official" version) the code from such a project, you would need to provide enough of the infrastructure that the original company provides, keep people interested in your version, and merge any "good" changes (while keeping in mind that you need to pay for each new version (the GPL does not gaurantee you future binaries, and you only get source to the binaries you have)) the original developers make.
Now if the company is charging too much for this service the competing free effort is likely to succed, but I believe that it is possible to hit a pricepoint, where it is more profitable (for the end user) to pay a small subscription/fee than to fork the project (and under the GPL any forks could be merged back in if they pop up and develop something useful). Not that it is easy, but it should be possible.
I disagree. While software has not been seen as a service until recently, I believe it has more potential for good as a service industry than it ever did as a product industry.
/not/ market a service. Even most manufactured products are produced only when ordered -- a request for service. The only difference is that in manufacturing, most of the cost over the lifetime of a product line is in mass production, and can be amortized to the cost per item. In software development, the vast majority of the cost is in the development, which indicates to me that the payment should be for the original development and not for the copies. Once the software has been developed, most often for a corporation but possibly under government contract or for a consumer organization, it could then become public, to be used by anyone.
When producing a product, it is necessary to predict what will sell on the open market for the best margin. This is not always the item most needed. It is not always produced by the best programmers. The product and its quality are determined by groups of individuals interested solely in maximizing the bottom line.
As a service, software would be produced when needed, to meet known requirements planned out in advance. The best team of programmers available will be chosen (for the money those interested are willing to offer -- and they are the ones to choose the cost, since they are the ones needing the software). There are very few "failed products" because the predictions are no longer necessary. In short, the process becomes far more efficient, and the developers end up making money in roughly direct proportion to the quality of their code (and general software development methods, such as staying on schedule) rather than the competence of their marketing department.
OSS is a service "industry". Software is developed, for the most part, because someone wanted it. There was a need for it. Generally, they chose to spend time rather than money to have it developed, having already the necessary skills to develop it themselves or a willingness to learn. They did not worry about what would sell well, or what the market wanted, because those did not matter. The need existed, and they chose to fulfill it. And while many an OSS project did not "succeed" in the market, nearly all accomplished the purposes for which they were written.
The software industry is one of a very few that does
The software doesn't have to become OSS, of course; it can be held under trade secret (contract law) if the company does not wish the resulting code to be used by its competitors. But in the case, it would be under a service model anyway -- with one copy, there is no difference.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
." There's a BIG difference between "nobody" and "hardly anybody".
..."
Heh; yeah, and it's often the difference between proprietary and open source.
I've also contributed code to a number of open-source projects. And in many cases, my work was triggered by reading a complaint from a user. I'd have the response "Hey, that's bothered me, too, and it looks like I'm not the only one. I wonder how hard it would be to fix?
Then, usually far too many hours later, I announce that I've got a patch that fixes the problem, and people should try it out. Or if it's simple enough, I just send in the patch in, it gets included in the next alpha/beta release, and I can reply to the original users complain saying that there's a fix in the archive for them to try.
With closed software, I couldn't have done this. If the code maintainers aren't following the same lists and groups as I am, they probably never notice the complaints. Or they are under pressure from their management to implement only the changes requested by Sales.
It isn't important that everyone hack the source code. What's important is that open source allows a significantly-larger crowd of programmers to hack the code. And it usually turns out that those programmers are users of the code themselves. This often makes them more responsive to user complaints than commercial developers, who usually only answer to their superiors (and are often intentionally kept out of direct contact with users).
And if the code's maintainers aren't responsive enough, open source allows you to do a fork. I've been involved in this, too. With closed source, it's only possible with permission of the original group. With open source, you sometimes (though rarely) get a fork that's more useful than the original. Or, more often, it's useful to a set of users that wouldn't have ever become users of the original.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
If this guy wants to be an ISV because he has a really novel and profitable piece of software in mind, he's going to get considerably stiffer competition than "some kid in his parents' basement". If his software turns a decent profit he's going to be up against other businesses that will be happy to invest serious resources to build a product that makes people want to pay them instead. The kid in the basement can try to build something better, and if he's got the resources to do that on his own, he'll be tempted to go commercial too.
People release things open source because they know that they don't have the resources to produce something complex on their own and to an agressive timescale needed to get to market while the money is still there. The super-successful open source projects draw their resources from a large number of contributors and take a while to get going. If these projects could reach new and lucrative markets while there was still big money to be made in them, the temptation to go commercial would be too much for many.