Why is open source used?
One obvious answer is so we can fix bugs ourselves, we have the source, we are techies so we can fix it our selves. But while it may be true that we can, we very rarely do!
I think ubiquity and 'fit for purpose' are the main reasons why open source is valuable.
All successful open source projects have grown from a need, the alternatives are no good!, too expensive or two restrictive, some individual(s) takes it upon him/her self to fix the situation. The evolving new solution, being a good fit for the problem at hand finds a niche; when the itch is common to many the way to scratch becomes popular. In the successful cases, the more popular a solution becomes the more refined it becomes. Ubiquity follows and the solution grows, either to embrace another problem or to become the groundwork for future work.
As a user of a successfuly open source project, the main motivation is to make use of the ubiquity in ones own work, if 50,000 developers are using ant to build their java projects then why don't I.
But will I fix a bug in ant, sure if it bugs me and I can't find a workaround in the community. But will I submit the bug back into the community, probably not. 1) because it takes time 2) because in doing so I undertake a substantial responsibility. I must make sure that all the tests pass, that no backward compatibly issues are introduced, lots of stuff, that a novice at making a fix to an open source project is not familiar with. I can make a suggestion, and the powers that be, thoes with commit access, will decide, but only if the underlying cause is simple and obvious; taking on the responsibly to diagnose, propose and implement a complex fix that is fit for the community is too onerous. Of course doing all of the above is no more that good engineering practice, but it takes time and familiarity, both of which I don't have and cannot easily achieve.
What often happens in my experience is that a fix is used locally, it is made work in a limited environment; however the investment and motivation to filter the fix back to the community is rare.
My point being that having the ability to fix the code is not that important, the fact that the we can get a free working solution to a real problem is the key feature. The free bit in its self is not even that important, we would happily pay, but being free means it is easy to access via a download, there is no lengthy procuring or licensing process. Well I tell a lie, every organisation worth its salt must have a licensing policy around the use of open source. However, for evaluation, the free bit only really makes a difference to ease of access.
That coupled with ubiquity, knowledge that it has worked well for others in a similar environment, are what makes the real difference.
Of course viewing the source does help to understand a solution, but those sufficiently interested to benefit are a rare breed :-)
Subscribe to:
Post Comments (Atom)
2 comments:
href="http://www.firstmonday.dk/issues/issue3_3/raymond/index.html#d9" This seminal work provides much of the insight into why Open source starts, flourishes and succeeds, one of the key trusims is captured by the phrase
18. To solve an interesting problem, start by finding a problem that is interesting to you.
Successful projects stem from solutions to personal every day problems that turn out to have mass appeal.
A useful article 'Open Source Ecosystems' at the pragmatic programmer throws light on a key aspect of open source. People’s reputations are on the line. I alluded to responsibility and in effect it is a responsibility to ones own reputation. By submitting a bug fix or proposing an alternative solution we put our reputation on the line.
"The first myth to dispel is that OS development is a kind of communal (or communist, as some suggest) hippy-freak love fest. Nothing is further from the truth. In the OS world, you are your reputation - all that matters is how well you do. Developers work hard to win that reputation by delivering high-quality code. Once won, they work even harder to protect it: submit poor code to an OS project, and the rest of the team will let you know in no uncertain terms - it’s their reputations on the line. As a result, OS communities are meritocracies, and each project is run by a (hopefully benevolent)
dictator."
Feeding back into the community for the first time takes confidence and courage, attributes not commonly associated with the software developer. This is changing however, as the vocabulary or language of software is becoming common tongue, more and more techies are realising their potential and taking the plunge.
Post a Comment