“Giving is its own reward.”
We’re all familiar with the overt benefits of open-sourcing internal company projects - free publicity; positive hiring influences; contributions from the open source community; and the warm, fuzzy feeling you get from giving back to the community. However, through the course of helping open-source Praxis, a Ruby-based API web framework that puts API design and documentation first, I recognized some unexpected, hidden benefits.
These covert benefits interrelate, but the common thread is that they were not obvious to me at the start of the journey to open-source Praxis. Note that this article focuses on benefits for the company which open-sources a project, in order to help developers champion more effectively within their company for open-sourcing projects.
Before going on, I’d like to mention that open-sourcing an internal project can be greatly beneficial, but it may not always be the right choice. For a good discussion on determining whether a project is a good candidate for open-sourcing, see the excellent blog Open Source (Almost) Everything by Tom Preston-Werner, founder and former CEO of GitHub, Inc.
So, without further ado, I’ll walk you through a few of the hidden benefits of open-sourcing projects and use RightScale’s experience with Praxis as an illustration.
#1 Code quality improves
“There is not a crime, there is not a dodge, there is not a trick, there is not a swindle, there is not a vice which does not live by secrecy.”
― Joseph Pulitzer
Let’s be honest. Like governments, when code lies in secrecy it makes it too easy to do the wrong thing. Without the light of third-party scrutiny, even the best-intentioned developers can make poor design decisions and damage long-term maintainability when they’re under the gun to release a feature quickly.
However, open-sourcing code means opening it to the public. Like a frumpy bachelor with bed head, you’ll have to shower, shave and comb your code to make it presentable before it steps out that open source door.
When we decided to open-source Praxis, we were thankfully given the time and resources to clean up the particularly smelly parts. We reorganized the code, separated pieces into gems in a saner way, and generally improved on its coherence, readability, and maintainability.
#2 Documentation gets better
When code is internal, the tendency is to put documentation last. RTFC (Read The Freaking Code) becomes the standard approach to documentation. However, when code is open-sourced, good documentation becomes a firm requirement. With the present open source climate being so positive, almost no one is going to bother using code that isn’t well-documented; the attitude is that, if the developer didn’t bother to document well, they clearly didn’t make it for anyone else. Additionally, documentation must also be accurate. These pressures combine to improve the documentation for open source projects.
Before Praxis became a public project, there was the equivalent of one wiki page describing it at a high-level. Virtually no documentation existed and developers felt pain when they ran into unexpected trouble. If you’re an experienced developer, this story may sound familiar to you.
Once we open-sourced Praxis, though, we released documentation at the same time. While documentation can always be improved, it is much better than what we had before.
#3 Versioning discipline improves
A common problem that internal projects can experience is that good versioning practices, such as Semantic Versioning, are treated more loosely. Imagine that a new feature is needed urgently for a business reason; it can be too easy to ship the fastest solution, even when it breaks backward compatibility. Quality Assurance (QA) testing is often used to catch breakages, because one can usually make the assumption that all users of the internal project are covered by QA automation. However, this serves as a source of frustration for developers, because they feel like the code changes under their feet without warning.
When a project’s source is opened, however, loose versioning usually is unacceptable. Developers anywhere in the world could be using the project, and it shouldn’t break when they update a minor version. By adhering to proper versioning practices, consumers know when an update will be safe or not. Open-sourcing Praxis has been a big win for RightScale because we get to benefit from stricter versioning practices. Although the current version of Praxis is still technically v0.18.1 and Semantic Versioning permits changes in the API before v1.x, in practice we have needed to be stricter because numerous Praxis-based services are running in production.
#4 Developer satisfaction goes up
In my experience, developers are usually more enthusiastic when they can work on open source projects. Such projects supercede corporate and monetary interests and appeal to our natural human tendency to seek a greater purpose. Working on open source also helps to build one’s reputation in the larger community. Developers are also subject to vanity of sorts - we like others to use the stuff we make.
If a project is open-sourced, developers are also more likely to go the extra mile to deliver quality. They are also more willing to spend time outside work improving the project. It becomes a labor of love instead of simply labor.
After Praxis was open-sourced, contributions from RightScale developers increased as compared to its closed-source days. This has included improvements in all areas, from serialization formats to the documentation generator.
#5 Internal adoption becomes easier
This benefit closely relates to all of the previous points - as code quality, versioning discipline, documentation, and subjective “fun-ness” of development all improve, it becomes easier to convince teams internally to use the open-sourced software. Teams within your company are on the hook to deliver high-quality, correct software, and open-sourcing an internal project sends a message to them that your organization is serious about the project by putting its image on the line. Internal teams feel more confident that the project will stick around and they have a clear way to contribute and get support when they need it.
Before open-sourcing Praxis, there was some internal resistance to adopting it as a framework for developing our APIs. Within RightScale, teams generally have the freedom to determine which technologies they use. Because Praxis was closed source, lacked documentation, and early adopters had experienced sudden changes breaking backward compatibility, it wasn’t a clear choice for all of our teams. However, after open-sourcing Praxis and seeing the improvements, the internal adoption conversation became much easier.
Conclusion
In summary, open-sourcing internal projects within your organization can be a very good thing. There are numerous benefits, often feeding off one another, and not all of them are obvious. When deciding whether it is worthwhile to open-source your company’s internal project, consider the hidden benefits discussed here. Open-sourcing an internal project is an example of how giving can be its own gift.
For more information about open source at RightScale, please check out our new RightScale Open Source showcase page. Happy open-sourcing!