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)).
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.