Open
The Open Source Software (OSS) approach can be loosely defined as the public release of source code to be freely viewed, modified, and redistributed under a given license. This short essay explores various aspects of the OSS model, touches on some common misconceptions, and considers some of its shortcomings.
It is easy to draw parallels between OSS and scientific research because the scientific method is, intrinsically, an open source process. Science is built on replication and peer-review; therefore, it is requisite that the methodology be made available for scrutiny. Since there are thousands of researchers working on all of its facets, science progresses at a rapid pace with a high level of accuracy and innovativeness. It is the sharing of ideas, work, and results that allows the whole process to function. In the same manner as scientific theories, software will become more robust if more people look at it, tinker with it, and break it.
It is not, however, a basic science. Open Source produces a tangible result—the software—in addition to its intellectual contributions. Thus it is most analogous to the applied biomedical and chemical fields where the goal is to produce an end product. Thus, unsurprisingly, commercial interests (especially IBM, Novell, etc.) are heavily involved in OSS, as they are with the other aforementioned applied fields.
Despite the similarities, OSS is fundamentally unique among the applied sciences in that the actual duplication and implementation cost is trivial. The code can be copied and inserted easily into an ongoing project with minimal effort. Additionally, software is unique in that widespread usage is generally advantageous (e.g. Apache) because that leads to more users uncovering bugs and submitting patches, which then contributes to the further propagation of the software.
Promoting usage is not the only motivation for choosing the open source development model. A project may be open sourced for a variety of reasons, but altruism is generally fairly low on the list. A common misconception is that, because the end product is given away for free, OSS developers will not be compensated for their work. The same could be said of other scientific research because the knowledge is being given without any expectation of direct repayment. This view avoids the importance of resume and reputation building. Showing a potential employer real, useful examples of one’s work is a large bonus; it shows enjoyment of coding and the possession of applicable programming knowledge. Additionally, one may get recommendations from within in the OSS community based on one’s work.
The aforementioned independent developers are predominant on small, specific projects, but paid OSS developers are now the principal contributors to most large OSS projects like Linux. Corporations often have several full-time software engineers working on various OSS projects. Their reasons for doing so can be placed into three distinct categories: (1) the company sells hardware that runs the target OSS project like Intel or IBM, (2) the company sells services that run or use the OSS project like Microsoft’s Azure, or (3) the company provides paid support for the OSS project, e.g. Novell or Red Hat. Richard Stallman may think that the association with industry is an inherent negative, but the current situation is a quantum improvement over the homogeneous closed-development models of the past.
Security is often other reason for choosing open source, albeit one that is perhaps slightly counterintuitive and hotly debated. Open-sourced cryptosystems have to, by definition, satisfy Kerckhoffs’s principle, which inherently makes them more robust than closed-sourced ones. That is, open sourced cryptosystems have to designed in such a way that they are secure even if everything about the system, except the private key itself, is publicly available. Pretty Good Privacy (PGP) is one such example; it is considered a military-grade cryptosystem and is completely open-sourced. Additionally, open-sourced cryptosystems build trust, because users know that there are no secret backdoors or glaring vulnerabilities. Cryptography systems designed with OSS in mind are immune to reverse engineering, contrasting with many “Security through obscurity” techniques. However, simply making the source available will not guarantee better security, as the recent Cryptocat debacle showed.
Rookie mistakes, like those committed by the Cryptocat developers, are only a subset of the limitations of open source:
Open source does work, but it is most definitely not a panacea. Software is hard. The issues aren’t that simple.
It suffers from many of the same difficulties that beset academia: the clashing of strong personalities working on the same project, lack of focus/direction (especially forking), focus on power users, among other things. That being said, open source is oft superior to closed-source solutions. It is with good reason that most supercomputers and mission-critical appliances run OSS. It is not a magic bullet and it will not lead to a free software “utopia.” It is software development that mirrors applied scientific research that offers a real solution to many real problems.