Advantages of Open Source Software

This work is licensed under a Creative Commons License.

Advantages of Open Source Software

Motivations for using and developing open source software are mixed, ranging from philosophical and ethical reasons to pure practical issues. In this subsection, some of the most widely proposed practical advantages will be introduced. For a discussion on some of the ethical issues (which is not covered in this document), refer to [25].

Usually, the first perceived advantage of open source models is the fact that open source software is made available gratis or at a low cost. But this characteristic is not exclusive to open source software, and several proprietary software products are made available in similar ways (a prominent case could be Microsoft's Internet Explorer). What really distinguishes open source software from software available without fee is the combination of effects due to the characteristics discussed in section 3.1. All of them combined produce a synergistic impact which is the cause of the real advantages of the open source model. Let us provide some more detail on how do these characteristics turn into advantages:

The availability of the source code and the right to modify it is very important. It enables the unlimited tuning and improvement of a software product. It also makes it possible to port the code to new hardware, to adapt it to changing conditions, and to reach a detailed understanding of how the system works. This is why many experts are reaching the conclusion that to really extend the lifetime of an application, it must be available in source form. In fact, no binary-only application more than 10 years old now survives in unmodified form, while several open source software systems from the 1980s are still in widespread use (although in many cases conveniently adapted to new environments). Source code availability also makes it much easier to isolate bugs, and (for a programmer) to fix them.

The right to redistribute modifications and improvements to the code, and to reuse other open source code, permits all the advantages due to the modifiability of the software to be shared by large communities. This is usually the point that differentiates open source software licences from ``nearly free'' ones. In substance, the fact that redistribution rights cannot be revoked, and that they are universal, is what attracts a substantial crowd of developers to work around open source software projects.

The right to use the software in any way. This, combined with redistribution rights, ensures (if the software is useful enough), a large population of users, which helps in turn to build up a market for support and customization of the software, which can only attract more and more developers to work in the project. This in turn helps to improve the quality of the product, and to improve its functionality. Which, once more, will cause more and more users to give the product a try, and probably to use it regularly.

The issue about non-exclusive rights on the software, which has just being mentioned, deserves some more attention. When no one holds exclusive rights on a given code (sometimes mentioned as ``life or death rights''), several traditional problems of the proprietary software model can be overcome:

There is no one with the power to restrict in a unilateral way how the software is used, even in a retroactive way. Such a power manifests, for instance, when a proprietary software vendor decides not to upgrade some software product for some old platform. In this case, customers can only stick to the old version of the software, or switch to another product. If open source software is used, customers can also fund some development for the desired platform, or look for other vendors to provide the upgrades (of the very same product).

There is no single entity on which the future of the software depends. This is a very common concern with proprietary software. Let us say that a company uses a software product, and relies on the software manufacturer for upgrades and continued development. If the software manufacturer closes doors, or decides to discontinue development of the product, no one has the right to take the program and continue development on it, effectively killing its usability in the market. This has happened many times, and this problem is amplified by the recent mergers in the software market, that usually lead to ``cannibalization'' of some software product to allow just one or two to get to the market. Open source software effectively protects against this, because if the group or company that originated the code decides to stop development, it is always possible to fund another software group to continue the maintenance and improvement, without legal nor practical limitations.

No ``black boxes'' are possible. This point is so important that open source is now considered by many experts as one of the necessary conditions for dependable applications. There are several reasons for this importance. One of them is related to the dependability of the services provided by a given software. By having the source code available, it is possible to perform a thorough inspection and verify the correctness of the algorithm and the implementation scheme used. This is also possible in part even with closed source or nearly free licences. The difference lies in the fact that users are allowed to modify everything they find appropriate to suit their needs. A glaring example is the Linux kernel and its ``international patches'', a set of enhancements with legal problems in some countries. These patches include support for encrypted communications, and can be legally used in large parts of the world. The patches have being developed by concerned parties in countries where such a development is allowed, and therefore users in those countries can use those enhancements. With binary only products no inspection is possible, with closed source or nearly free licences inspection is possible, but modifications are forbidden, so the inherent advantage of having source code available is rendered ineffective.

There is always the possibility of ``forking'', or creating an alternative code base if the current one is in some way perceived as wrongly managed. This is sometimes considered a disadvantage, having to manage not only one code base, but two. A ``fork'' is a subdivision of the code base in two different parts, each managed by a different group. Forks happens for technical or licence reasons, for example because a particular release is made under a non-free licence, the previous one is used as a base for subsequent free releases. Technical motivations are common, because there are sometimes many different way to perform a task, and it is not possible to decide which is better. So if the two camps cannot reach a consensus and the user base is large enough the code splits in two, and both continue development. If the reasons for the split are overcome, usually the two camps agree on a reunification. A recent example is the decision to reunify the compilers gcc and egcs, and to make one of them (egcs) the new base compiler. In other cases a fork is used as a way to coordinate work. An example is the Linux kernel, where two distinct code bases are used, one ``stable'' and one ``experimental''. This way it is possible to introduce new and potentially dangerous technologies without disrupting the stable ones. So, people interested in leading edge technologies can try them, and people that uses the Linux kernel in production environments can count on stable and tested features.
But the main point about forking is that it introduces several levels of competition within the model. For instance, before forking, several programmers can work harder to keep everybody happy integrating as many well-engineered features as possible, to prevent a fork by people whose needs are not addressed. After a fork, both branches tend to compete for the user base with very similar products: only good quality and quick improvement can maintain them in the market.

No per-copy fees can be asked for modified versions, and anyone can use the current code base to start new projects. Working knowledge can be gathered at a minimal cost. This is what made Internet software systems such an important factor in the new economy: students, and people trying new technologies were able to integrate and adopt them immediately, without the hurdles of commercial or non-disclosure licence agreements. In addition, the right to freely modify them allowed for the incredible expansion in the number of communication protocols and systems, each perfectly tailored to the needs of their users. This is also a reason for the overwhelming success of the Linux kernel, widely employed by students thanks to its near-zero cost, and subsequently used by the same students in the startups originated by them, when they turn into entrepreneurs after leaving University.

There are fewer conflicting priorities due to marketing pressures. This is a simple consequence of the fact that there is no single commercial entity pushing for precise delivery dates or features that must be supported. Usually open source software is delivered ``when it is ready'', and when the development team feels that its quality is good enough. This means that software usually does not need as many ``service packs'', updates and such, reducing the maintenance cost. Of course this could be turned into disadvantage if a product is indefinitely delayed, or if some feature is missing one release after another. But in this case, the competition between projects may help. If a project starts failing to meet the expectations of its users, it often happens that a new project is forked, using the same code base, to fill this gap. This happens especially if a market exists for some new features, or for better quality versions of the application.

It provides a new forum for democratic action. As individuals and companies decide where to make improvements in the system, the collective desires of the community determine the overall direction of progress, and yet without compelling anyone. People with opinions about what direction is best can urge others to join in, request help, and in this way influence the overall direction of progress, but without any elections in which the majority overrule the minority.

http://eu.conecta.it/paper/Advantages_open_source_soft.html

Perceived disadvantages of open source models

Of course, open source development models lead also to the perception of some disadvantages. However, some of them are only disadvantages if we are stick to classical (proprietary) development models, which is of course not the case with open source. Let us review some of them:

There is no guarantee that development will happen. In other words: it is not possible to know if a project will ever reach a usable stage, and even if it reaches it, it may die later if there is not enough interest. Of course, this is also a problem with proprietary software, but it is more evident in the case of open source. Especially when a project is started without strong backing from one or more companies, there is a significant initial gap, when the source base is still immature and the development base is still being built. If it is not possible to get funding or enough programmers cooperating at this stage, the project just ``dies'', or perhaps slowly fades out. Usually, when it reaches a self-sustaining level, the user and development base is such that it can proceed by itself, without other external incentives. This issue will be revisited later on, when business models are discussed in section 5.

There may be significant problems connected to intellectual property. This point is especially important, now that some countries are accepting software and algorithm patents. It is very difficult to know if some particular method to solve a software problem is patented, and so the community can be considered guilty of intellectual property infringement. Some open source packages are already addressing this issue with switches or patches that enable or disable patented code fragments according to the country where the code is used. In other cases, developers consider source code not as an executable device, but a mere description of how a device (the computer) executes, and therefore uphold the idea that source code is not by itself (in absence of an executable program) covered by patent law even in countries where software patents are accepted. However, this idea has still to be tested in courts, and many people do not believe in its viability. In any case, it still leaves problems for the users, who need the executable programs. Although the issue of software patents is a problem for the whole software industry, open source is probably one of the more clear cases where it can be shown how they harm the regular process of software development. The specific problems are that availability of source code simplifies the detection of patent infringements by patent holders, and that the absence of a company that holds all the rights on the software also makes it difficult to use the mechanisms in use by companies to defend from patent litigation, like cross-licensing or payment of royalties. These issues will be discussed with some detail in subsection 6.2.

It is sometimes difficult to know that a project exist, and its current status. There is not much advertising for open source software, especially for those projects not directly backed by a company willing to invest resources in marketing campaigns. However, several `aggregation points' for open source software do exist¹⁵
, although in many cases they are usable only by experts, and not by the general public. They are also in many cases very specific to some software category, such as scientific software or database systems. There are only a few `clearing houses' for open source software and projects, and in many cases they are not really up to date. However, some people see this fact as a market opportunity, and several companies with experience in Internet based information services are approaching open source software with added value services which maintain information useful for people or companies trying to locate or evaluate open source software of some given characteristics. In fact, a new business is emerging for providing consulting and searching services related to the selection of open source applications for specific needs. For the general public, some more education is still needed before the regular user can approach these services and get a solution to her software problems in terms of open source software.

It is extremely important to `see' through the various interpretations of the advantages and disadvantages of open source, and if possible try to analyze with quantitative methods if open source can be helpful in a given situation, or for a given user or company. From a developer point of view, a good example of the perils of launching an open source project is the Mozilla project (launched by Netscape in 1998), considered by some people a complete failure because it took more than an year to get a first beta out. On the contrary, other people perceive, with respect to the same project, that the open source community was capable of producing a totally new code base (larger than the Linux kernel) starting with only some new infrastructure. In fact, now half of the developers of Mozilla work outside of Netscape, and the Mozilla browser has begun to be embedded in many innovative devices, thanks to its modularity and flexibility (for a detailed discussion on the evolution and results of the Mozilla project, read [6]).

Cooperation and competition

If the characteristics of open source development models were to be defined by a unique expression, `cooperation and competition' would probably be the one to choose. Indeed, the combination of both mechanisms is visible in almost any open source project, not to mention when we look at the big picture, where every project and company is in some sense competing with others for resources and `market acceptance', while collaborating with the reuse of the same code base. Let us provide some detail on how those mechanisms work, and enforce each other in a very productive mixture.

Cooperation within open source projects. Developers participating in the same project, usually cooperate at levels higher than those usual in proprietary software projects. The design phase is usually completely open, with all developers collaborating, and during the coding phase is quite common that a developer reads and fixes bugs in the code being developed by another. The flux of information is usually very high, and problems are solved by consensus among at least the core developers. All of this together, in addition to be more effective, usually causes the developers to be more committed to the project, and makes their work much easier, thanks to the help of other developers.

Competition within open source projects. Within open source projects there is also some degree of competition. Most of them are organized as some kind of meritocracy, where the developer who does more for the project deserves more credit, and is given more weight in decisions. This allows for a certain level of healthy competition between the developers, from which the leaders of the project (when such leaders do exist) usually emerge. This is still a fact not understood by many companies, which need to realize that in order to participate in the decisions about future directions of a project they need to have some respected developers within it.

Cooperation between open source projects. The very nature of open source licences ensure a high degree of collaboration, even between competing companies. This is for instance the case of the many companies selling distributions of GNU/Linux. All of them share the same code base (the GNU/Linux operating system and applications), and whenever one of them fixes a bug, or improves a package, all its competitors have access to the source code, and thus to the same fix or improvement. Therefore, projects and companies in the open source world are compelled to collaborate by the open source model. And when they try to avoid helping their competitors, they have to move away from the open source model, which usually gives them more problems than benefits.

Competition between open source projects. But in a world of limited resources, open source projects also compete between themselves. Projects developing software for the same niche compete with each other in a way similar to companies in that niche competing. In the end, they are forced to maintain high levels of quality, or they will lose users and developers, and will finally fade away. In fact, this is one of the mechanisms which ensures a good quality in open source production. When a project starts failing in terms of perceived quality or management, there is a chance that some of the developers will open an independent development branch. This branch soon becomes an independent project, perhaps using a similar code base, which starts to compete with the old one. This competition usually causes both teams to improve their product, and in the long term, one can become mainstream while the other becomes marginal, or they can diverge giving special attention to different issues. This is, for instance, the case with NetBSD, FreeBSD, and OpenBSD, all of them sharing similar code, each with a different focus, and all of them exhibiting a high quality product.

Usually, this mixture of competition and collaboration is not intentional, but the product of the development model, and of the licenses used in open source projects. In short, everybody is forced to compete by exposing the tools (the source code) they are using, and improvements are quick to spread through the competing projects, in a manner quite different to the traditional software industry. Competition and collaboration are probably the ultimate cause of the high efficiency (in terms of quality and quantity of software produced with a given set of resources) which open source projects reach.

Top