In Part 1 of this 3-part series we explore the apparent triumph of open source software over its antiquated counterpart, proprietary software.
In the battle between software created openly by anyone who wants to contribute and those rigidly coded in closed shops, it was no contest. If you used closed source software and you wanted new features or bugs fixed, you had to wait for the product to change, complain about it, or develop a workaround, hoping the change made it into the product someday. With open source, you can participate by offering changes and improvements yourself, as long as you can demonstrate that you are willing to be part of their community.
Subsequently, closed software shops are starting to take note and incorporate open source in their process. Not only are corporations open sourcing more and more pieces of their custom stack, they’re also incorporating the techniques and processes that make open source so successful.
This is called InnerSource: open source software development within a corporate engineering organization. It’s an exciting shift in how software is developed and frees up individual contributors to allow significant changes outside of their silos. To get a better sense of what these practices look like in the real world, we talked to Danese Cooper, Founder and Chairperson at InnerSource Commons, and longtime open source advocate.
When open source software started becoming popular, many feared it would lead to more bugs, security holes, and other issues. But open source codebases have been found to create bugs at a slower rate than closed ones. “The secret sauce of the open source method is the fact that it’s transparent. Many eyes make small work of all bugs,” said Cooper.
If you’ve spent a lot of time reviewing your own text, be it writing or code, you probably had the experience of missing simple errors because you’re too familiar with the text. Reading it over, you see what’s in your mind, not on the screen. When open source working styles get incorporated into a closed shop through InnerSource, you get a fresh eye on your work, and those eyes see the problems you’ve missed.
Beyond spotting bugs, new perspectives can also introduce fresh solutions or optimizations. This is possible because InnerSource favors an open contribution model. Anyone on any team can place changes into a pull request and have the product owner review them for inclusion in the product. Just as in many open source projects, this doesn’t mean it’s a free-for-all. Each codebase—be it a service within a larger service-oriented architecture, a feature within a monolith, or a product within a company’s suite of products—has a set of trusted committers: people who review all commits and approve them into production.
Join us for Part 2 of this series to learn more about process-driven InnerSource key elements.
Want to learn more? Listen to Intuit’s Journey to InnerSource.
Join Stack Overflow’s Director of Product Vasudha Swaminathan, as she sits down with the members of Intuit’s engineering team to discuss all things InnerSource. You’ll learn:
What is InnerSource?
The benefits of InnerSourcing
How to gain support and adoption
How to enable collaboration across decentralized teams
What tools support InnerSourcing