Before we dig into the details that will come out of individual interviews, let’s note some of the assertions being made by the proponents of either model. Both sides make statements about the superiority of their results. Many of these statements seem counter intuitive or even contradictory. For instance, Open Source proponents say their products are more secure because the source is available to everyone and gets more thoroughly examined for vulnerabilities, while Closed Source advocates say their products are more secure because the code is kept as a proprietary secret among a few developers. That’s like someone saying “my shirt is better than yours because it’s blue,” to which the other responds: “On the contrary, mine is better because it’s not blue.” Though we won’t try to individually debunk or sign on to any of these assertions in this post, it would be helpful to understand what they are as we go forward.
What are some of these assertions?
SOFTWARE SECURITY
Open Source:
- “Many eyeballs” make code more secure. That is, since more people have access to the code, it will be more thoroughly scrutinized for problems.
- Since there are more hands available, the open source community responds more quickly to discovered vulnerabilities than the closed source community does.
Closed Source:
- Obscurity of source code makes a product more secure. Since the code can’t be examined for weaknesses by hackers, it’s more difficult to break into the running system.
- Formal security reviews as part of the development process result in a more secure final product.
- A formal structure exists for evaluating and prioritizing vulnerabilities.
DOCUMENTATION
Open Source:
- Since the documentation is written by real members of the community, who are often experts in the field being served, it will be more complete.
- Since the documentation often includes wikis, forums, and other interactive, online forms, it stays up to date; the community interacts synergistically to address new behaviors and documentation inaccuracies.
Closed Source:
- Documentation is better because corporations pay people to write it.
- Documentation is clearer because review processes ensure that it is presented in a consistent format.
QUALITY
Open Source:
- Because of “many eyeballs” on the source code, Open Source products are generally higher quality.
Closed Source:
- Due to formal testing and review during implementation, Closed Source products are generally higher quality.
EVOLUTION
Open Source:
- Since an Open Source project is managed by the community it serves, new features tend to be highly focused on the community’s needs.
- Since there are many programmers working on the code, new features are delivered more often and with greater regularity.
- Since the code is open, new features that address only a small subset of the community are still likely to be introduced.
Closed Source:
- Since new features are added as a function of customer feedback and market analysis, they are more likely to address the issues most important to users.
- Since new features are introduced in the context of product version releases, they will work out of the box.
SUPPORT
Open Source:
- Support is generally offered through online forums, so an issue will be seen and addressed by many. This makes support faster and more reliable.
Closed Source:
- Support is handled by a paid staff. This means all issues will be addressed promptly. This makes support faster and more reliable.
LONGEVITY
Open Source:
- Since an Open Source project is managed by the community it serves, it will continue to grow as long as there is community need for the product. With Closed Source products, the community is subject to the whim, and continued success of the company producing the product.
- Even if a project stops producing new releases of a product, the source code is available, so individual users can support themselves and maintain their installations.
Closed Source:
- As long as a product is profitable, it is serving the community and will continue to be advanced and available. With Open Source projects, there is no guarantee of continued advancement; the community is at the mercy of the whims of the contributing programmers.
I find all these assertions interesting. Some attributes of each delivery model are seen as an advantage by the proponents of that model, and as a disadvantage by the proponents of the other model. I suspect most of these assertions may be true in a sense, but they are probably robustly true only in the best run projects, whether open or closed source.
Which of these assertions do you think are valid? Which do you think aren’t? Why? Can you offer examples in support for, or opposition to any of these? What are other assertions made by these two communities?
