Open Source Benefits for DevelopersEric Wilhelm
There has been much discussion about open source software, but the public discourse has failed to produce a compelling reason for a commercial developer to initiate development of a new program under an open source methodology and license. There are several benefits to this approach, with the only real drawback being that your economic model cannot simply revolve around trade secrets. The question of "how to make money" developing open source software is an entirely different article. The purpose here is only to explore the why of open source.
What you get out of open source software depends on who you are and what you are trying to accomplish. It is tempting to try to categorize, but a look at the categories below shows that any such attempts are going to be plagued by overlap.
Many people easily span all of the above categories. Yet, where it seems natural to combine two categories, the nature of open source creates new distinctions. Even in proprietary software, the category "customers" does not completely contain all of those that could be filed under "users".
Because of these difficulties, it is better to separate the discussion into parts of a software process.
To clarify the discussion, we must first forget about some of the assumptions about open source.
Freedom. Not Free Beer
The desire for freedom, which started the open source movement, stems from a desire to be free to share ideas. By coincidence, software is a special kind of idea which can be rendered into an executable form. Thus, the freedoms which are required to facilitate the sharing of ideas also happen to enable freeloading.
Open Source Does Not Mean Volunteer Labor
Most existing success stories of open source software represent the product of decentralized volunteer development communities. This phenomenon depends on these communities working in an open source methodology, but the dependency here is one-directional. A commercial company with all of its developers working in one office could easily choose to adopt an open source methodology. Decentralized development communities cannot function effectively without one.
Commercial companies wishing to initiate an open source project should realize that open vs. closed only represents the state of a door. While you may have left the door open to volunteer labor, there is not a group of developers on the other side of that door waiting to come in and contribute free code. The probability of receiving contributed code when the door is closed is obviously zero. What you are actually interested in is the probability that there is someone outside the door wanting to contribute code. This probability increases only slightly when you leave the door open, and is primarily a function of time. Over time, depending on how interesting or useful your software becomes, there will be someone with an idea that your developers have not had.
The various open source licenses and business models are outside the scope of this article. However, it deserves mentioning that some business models can effectively make this a one-way door. If your plan is to dual-license the software, you must own the copyright on every single line of code or any contributors must assign you the right to resell their work under your second license.
Every project has to start somewhere. With open source, you have a wealth of options from the very beginning and an opportunity to reduce your startup overhead by reusing existing open source code (libraries) and leveraging tools that are not feasible if the code must be kept secret. If your software is going to be open source, you effectively get the chance to be a user of open source libraries and even code from other projects.
No Need to Reinvent the Wheel
Every software project has some basic underlying functionality. While public-domain code has been made available in many cases, there are many open-source libraries which provide functionality that you would otherwise have to build yourself or license as a black box. Some licenses allow you to use open source libraries in proprietary code, but you have a wider range of options when your project is open source.
Even in the case that you have to build libraries in-house, there are benefits to making those libraries an open source project. We will discuss these more in the next section.
Debugging a problem in your code will often lead you to a library call. In most cases, the problem actually originates in your code, but this is hard to trace through a black-box library. With open source libraries, you are able to clearly see what happens inside the box and therefore able to debug your application more efficiently.
When your strategy does not revolve around trade secrets, you no longer need to get everybody involved to sign a Non-Disclosure Agreement (NDA) and persuade potential hires to write-off several years of their life with non-competition clauses in their contracts.
Your developers will be happier, because they can freely discuss their jobs outside of work instead of having to cut off potential conversations with "it's a secret." Openness allows your developers to speak freely at conferences and participate in technical discussions. This exchange of ideas allows you to be part of a community, and also drives innovation.
Unnecessary Work and Frustration
How much time and money goes into getting your licensing server or other DRM scheme working and supported in all of your target environments? How frustrated are your customers with per-machine licenses and other associated restrictions? If the software is open source, all of these issues go away.
It is no secret that the best businesses have the best employees. A successful company wants to attract talent with the promise of exciting work and long-term benefits.
Developers Keep the Code
A developer working on open source code is much happier than one who knows that their code may never see the light of day. Even if the project tanks, the developer has the guarantee that what they've written will not be flushed down the drain.
The Best Idea Wins
Nobody wants to be told that their idea will not get used because of some non-technical factor. Egos will recover if the idea really is bad, but resentment of "because marketing said so" does not heal so easily (and won't work at all in an open source process.) The open source project must be run in such a way that the best code is always the best solution. If a sales or marketing ploy required the software to under-perform, the user-base would quickly take matters into their own hands and the vendor would lose the respect which is crucial to maintaining leadership in open source.
Friendly, Open Environment
As mentioned in "Open Discussion", developers can feel free to discuss what they're working on. They enjoy chatting with power-users on IRC and overseeing discussions on mailing lists. If a thriving community forms around the software, your developers will think they've got the coolest jobs in the world (and so will lots of people that use the software.) This gives you happier staff and better quality than is possible when you have isolated your developers from their users.
If you are developing desktop software, the perceived quality of your software is going to come primarily from the user experience. This means that the responsiveness, interaction design, and other human factors must all be well-handled, but there are several limiting factors to software quality.
Jamie Zawinski described the open source process as "working in a fishbowl."1 This means that the developer is always aware that the world is watching. Ugly code goes on your permanent record and harms your reputation. Because beautiful code means beautiful software, the quality ceiling is much higher with open source. Developers know that bad decisions are open to public ridicule.
Many people would not cheat when someone could be watching, but will confidently cut corners when no one is watching. Furthermore, years of effective discipline tends to result in habitual integrity.
We are what we repeatedly do. Excellence, then, is not an act, but a habit.
If you manage a development team, consider the benefit of having your developers constantly thinking that "someone is always watching" without the stigma of that "someone" being you.
Anyone who has worked in computer security for a few hours knows that "security through obscurity" does not work. Because an open source process requires you to implement real security, the tempting shortcut of just keeping the mechanism secret is out of the question. This forces you to work harder, but results in better security by openly allowing third-party audits.
An open source process provides a lower bug "floor" than a proprietary process. This comes from the simple fact that there are more people outside of your company than inside. "Given enough eyeballs, all bugs are shallow"2 is also an open-door issue. A proprietary development model requires you to shut the door on users who might otherwise be finding bugs for you.
Maintenance & Internal Development
The biggest maintenance issue in software is with companies that have developed custom applications with in-house staff. Because maintenance represents 50% of the lifetime cost of software, an open source strategy may enable such companies to eliminate a significant portion of this cost. Because many of the original developers of custom applications have moved on or retired, any maintenance tends to involve a significant amount of time spent familiarizing oneself with the code. If the software is an open source project which is in use worldwide, the chances of finding a consultant who is familiar with the code are greatly increased.
Many of the same benefits that you as a developer get out of open source also come down in favor of your customers. For a similar analysis of the user's point of view, see the article Open Source Benefits for Users.
This article is meant to illustrate that the open source development process is able to exist independently from a volunteer programming phenomenon and that it is an approach which merits serious consideration. Any business venture involves some degree of risk, though advantages such as a good plan, a talented team, and other factors can tip the scales in your favor. The above benefits may further reduce the risk of a new software endeavor. While the details of your business model and sales strategy may seem puzzling, it is far less so if you have these tangible benefits in mind.