No politics. Everyone is truly for the good of the project, nothing else. For example if someone feels that a refactoring is needed, he will just do it without worrying if he should focus on features development so that velocity looks good.
Better recruiting process: 1) only people really love the project will try to get on the project, 2) skill can be tested again and again thru the patches new candidates submit. In another sentence, candidates are evaluated by the real work they do on the project and no bias of any kind. This process can take as long as needed since in the same time the candidates are contributing the project.
Developers are forced to focus on good code quality. Because every single line of code needs to be highly consumable by other committers who, when they need to continue this work, usually don't have the context and may never get the chance to talk to the developer who wrote it. Readability and tests are absolute must-haves, because that's all other developers can count on.
More sense of achievement because the well designed code can be appreciated by a much broader audience in an open source project. Some say that programming is like art (and I believe they are talking about the code not the front end UI), then artists certainly appreciate more recognition of their work.
Wednesday, May 18, 2011
Why community driven open source teams produce high quality software?
A community driven open source project is an open source project that is completely driven by an online community of developers where there is no organizational structure. Developers are contributing on their own time without getting paid except maybe donation. Also, they are free to leave the project at any point. Why would such projects produce many times higher quality software than closed source software project developed by teams with scientific management and stringent accountability?
Subscribe to:
Post Comments (Atom)
This may all be true, but what if at one point in time none of the commiters have any more interest in a project? Thats a real blocker for all that are using it in real production environments. Look at yourself and NH Burrow. And NH itself is about to go this way.
ReplyDeleteSo maybe the quality is good and mostly better but for real world projects it is nothing you can count on.
To some extent I agree with you. Committers leave project normally because they themselves no longer need it and if the project itself can't attract enough contributors to succeed them it will fail. Burrow is lightweight and small amount of code that I think client dev can manage themselves. but if you are picking a real complicated library (such NH), it is important to evaluate the strength of its community. But I wouldn't say it's a sin of OSS itself. A small OSS community is definitely more fragile than big companies like MS, but it's not necessarily more fragile than other similar sized organizations. I mean, I would still prefer NH to commercial .NET ORM products provided by small companies in the market.
ReplyDelete