Reading 08: The craftsmanship model is still valid
I personally think that the greatest thing driving someone to participate in open source, above all else, is simply the need or want to create something (or improve/fix something) that they use. When people first start programming, and first start learning about open source software and the idea of free software, generally do not become ideologically fanatical about it and willing to contribute to open source purely because of their beliefs. For most people, their first contributions to open source are a small project that they’re proud of, or some fixes/features to a project that they use. It is only afterwards, as these people begin to use more open source software, and begin to contribute to more software that they begin to see the reasons that many programmers are fanatical about free and open source software.
Once people see why so many programmers contribute to open source software simply to further the cause of open source software (and in some cases to further their reputation as well), some will be persuaded by those arguments and begin to contribute to open source projects to help out, and also to build a name for themselves. But in my opinion, some contribute to open source simply because they want to create an elegant piece of software. I reject the idea that the only way to maximize quality is through peer evaluation. I believe that it is certainly a good way to do so, but the idea that it is the only way is something that I completely disagree with. You can maximize quality entirely on your own, focusing solely on your own software and some principles of software development (the unix philosophy, for example). I think of some small pieces of software that I have been working on - I haven’t released them yet, I have no feedback so far, but I already know what I want to work on and what I want to tinker with when I’m done. The only peer I need evaluation from is myself, and he has very good taste. I’m being a little facetious, but I don’t think you need peer evaluation because I believe the opinions of the creator allow for an open source project to have goals to work towards, and that these provide sufficient motivation for (some) hackers.
As for what prevents people from contributing, I think part of it is that this culture is very niche and difficult to understand for outsiders - it is pretty difficult for someone who’s never heard of the unix philosophy, or unfamiliar with the history of open source software / early hackers to understand why people are spending so much time creating software for free, instead of using their talents to sell it, especially in the society we live in. In addition, for many people it is daunting to create a project, especially when there is a good chance that something like it already exists. A lot of people may just not want to recreate the wheel, unless they have a sort of inbuilt drive to hack.
I think the list of taboos that ESR lists are essential to maintaining a community. Many hackers (not all, as I disagree with ESR) are motivated by their reputation when creating open source projects. If the taboos against forking / distributing changes were not present, then many hackers would be disillusioned if they found their work being distributed by someone else, with their name removed and given no credit, especially if the changes were not to their liking (if your software is like your baby, seeing someone else dress it up in a way you don’t is repulsive). These norms are essential to maintaining a community that rewards developers with attention and reputation, some of the few ways to reward developers in a community which doesn’t pay them.
Once people see why so many programmers contribute to open source software simply to further the cause of open source software (and in some cases to further their reputation as well), some will be persuaded by those arguments and begin to contribute to open source projects to help out, and also to build a name for themselves. But in my opinion, some contribute to open source simply because they want to create an elegant piece of software. I reject the idea that the only way to maximize quality is through peer evaluation. I believe that it is certainly a good way to do so, but the idea that it is the only way is something that I completely disagree with. You can maximize quality entirely on your own, focusing solely on your own software and some principles of software development (the unix philosophy, for example). I think of some small pieces of software that I have been working on - I haven’t released them yet, I have no feedback so far, but I already know what I want to work on and what I want to tinker with when I’m done. The only peer I need evaluation from is myself, and he has very good taste. I’m being a little facetious, but I don’t think you need peer evaluation because I believe the opinions of the creator allow for an open source project to have goals to work towards, and that these provide sufficient motivation for (some) hackers.
As for what prevents people from contributing, I think part of it is that this culture is very niche and difficult to understand for outsiders - it is pretty difficult for someone who’s never heard of the unix philosophy, or unfamiliar with the history of open source software / early hackers to understand why people are spending so much time creating software for free, instead of using their talents to sell it, especially in the society we live in. In addition, for many people it is daunting to create a project, especially when there is a good chance that something like it already exists. A lot of people may just not want to recreate the wheel, unless they have a sort of inbuilt drive to hack.
I think the list of taboos that ESR lists are essential to maintaining a community. Many hackers (not all, as I disagree with ESR) are motivated by their reputation when creating open source projects. If the taboos against forking / distributing changes were not present, then many hackers would be disillusioned if they found their work being distributed by someone else, with their name removed and given no credit, especially if the changes were not to their liking (if your software is like your baby, seeing someone else dress it up in a way you don’t is repulsive). These norms are essential to maintaining a community that rewards developers with attention and reputation, some of the few ways to reward developers in a community which doesn’t pay them.
Comments
Post a Comment