What Open Source is doing right, posted 29 Mar 2000 by eivind (Master)

If there's something that we're doing right intrinsically, we should try to enshrine that. But the software engineer in me says we're doing the wrong thing - according to all my software engineering texts and best practice I've come across during my security code reviews at various companies how OSS software is developed should never work, and we should have the buggiest and least stable environment. But it's not. That's what I'm getting at.

We are doing a lot of things right intristically. Below are some of the (to me) most obvious factors, in no prioritized order. They probably aren't the complete picture, but they at least give a sketch.

'We' below refer to the Open Source developers in the established Open Source community.

  1. The developers are usually not doing development to a deadline or to solve a business problem.

    Most Open Source development is done out of love. This result in programmer satisfaction being the most important aspect of the development, and most developers like writing good software, and do not like having bugs in their software. This tend to influence development priorities.

  2. The most recent code is actually in production and pseudo-production use.

    Open Source (when developed by the bazaar model) is associated with frequent releases, both of stable and development branches. This result in rapid feedback about changes, and in pressure to keep the code functional - a project that is on its way into a swamp full of bugs will get branched from the last stable version.

  3. We make small stuff.

    Just about all open source projects effectively build small stuff. We might build large stuff by building a lot of small stuff after each other, but each piece is small stuff, because we do not have the infrastructure to try to build large stuff up front.

  4. We automatically try for the simplest solution to a problem.

    An Open Source codebase tends to move towards maximum usability. If a simple change can make the system more usable (for a very generic definition of user), that change tend to be done, unless there are complelling reasons not to. This is a clear opposition to commercially sold software, where the driving force is to make the code more sellable, not more usable.

    In the move towards maximum usability, we have a lot of programmers looking at most of our software. If one of them see a simple way to improve the software for her own use, she will do the change. This automatically select simple solutions, because the simple solutions will be available before the complex solution.

  5. We work with patches.

    In most other environments, programmers will just work directly against the source code, and somehow commit the code for the production/development version once he's done his changes. Any change handling is usually done by a version control system.

    Open Source developers, on the other hand, tend to get submissions as patches, and thus tend to have a conscious view of the changes themselves (on a line by line basis) rather than just the end product. This creates a very effective review and feedback loop, even for the programmer that is working on a codebase alone.

  6. We know how to read source code.

    Most Open Source projects do not have a bunch of UML diagrams, or an available architect to describe in detail how things work and where to find them each time a neophyte wonders about something. This forces the neophyte to learn to read code well enough to find out many of these things for himself; this again gives feedback towards being good at understanding code, with the side effect of becoming better at spotting when code doesn't work and at reading patches.

  7. We stick with a common set of basic tools.

    diff. patch. Your basic text editor. Your basic shell. The C library. The Unix system interface. Root as the basic owner of all rights. make. Devices in /dev. X windows. The basic Unix commands. The languages we use.

    All of these has history going back over 10 years; many of them has stayed more or less constant for 15 to 30 years. With this, we have a common, simple backdrop to do our development in. We do not have to re-learn our tools every two to three years. This leads to a second backdrop: A lot of people with vast experience in the tools and in development, controlling part of the culture of open source.

  8. We practice program/system evolution.

    A really bad open source system dies from lack of users. A really bad commercial system has more programmers and more money pushed into it if that can result in more income later.

  9. We are 'Best Of Breed' programmers

    This might seem a bit snotty, but Open Source attracts developers that see development as fun, not just as a way of making a buck. This is an effective filter for getting people that are really interested in development, and thus tend to be good at it.

    The rather harsh environment of the Internet also tend to force some of the qualities good developers should have - e.g, participation in discussion forums tend to force people to distinguish between what they know and what their opinions are.

  10. Through the peer review, we end up with rapid feedback on how we write bad code.

    All developers have some bad habits. Open Source programmers usually start with submitting patches to existing projects; this forces them through a layer of peer review, which pick away some of the bad habits. Out comes a better programmer, about to start writing more Open Source software.

  11. We have access to a set of good programmers to discuss ideas with that outstrip any commercial entity in the world.

    As argued above, Open Source programmers tend to be above average. For just about any significant project, a lot of them are available to get feedback on design issues, and to production test any runnable code. There are way more qualified programmer time available than for most commercial projects.

    As an example: Some time ago, I started a low-key project to create a new version control system (to replace CVS and other horrors.) As I didn't (and don't) want to hype it until runnable code was (is) available, I only contacted a few friends of mine to tell about this, inviting them to join the design/review team. Within 24 hours, I had over 100 years of programming experience on the team, collected within approx 7 people. Getting allocated time from a comparably sized group with over a 100 years of accumulated experience would be close impossible in a commercial setting.

  12. We have a culture of mass communication.

    The Open Source community routinely use mass communication tools. Usenet, mailing lists, Slashdot, IRC, FTP, CVS, diffs. All of these are designed or have been tweaked to function as communication tools between large groups of people. This allow much easier use of many pairs of eyeballs than the corresponding tools that commercial developers tend to use.

  13. For codebases that have seen widespread use, nobody can force bad changes on the codebase.

    This isn't quite true, but for bad changes to be accepted (even from a maintainer), they have to be heavily outweighted by good changes. If not, the codebase will be branched, either locally or globally.

  14. Authors tend to stick around.

    In a commerical setting, a developer is no longer available when she changes jobs. In an Open Source setting, the original developer of a piece of code is usually available for quite a few years after the initial development, and if she disappears, somebody else will usually learn the code and start acting as a new "Source Of All Knowledge" (for the tricky parts) - unless there is a group of people already doing that through one of our mass communication channels.

  15. Development tend to go slower.

    Open Source developers usually push fewer hours per day into the codebases than commercial developers. This result in more time to think about each change, and more time to get feedback. If a better way to do a change is proposed, the developer will often take the time to do it "The Right Way", even if the original way of doing it is adequate.

  16. Open Source is better because Open Source is better.

    This is self-referential, but I believe it is true: The quality of open source tends to attract developers that like quality, thus getting a feedback loop where the developers that use and develop Open Source likes to make more quality software.