The Secret Sauce to Open Source
By Jim Jagielski, Sr. Director of the Tech Fellows program, Capital One
One of the first items discussed when companies start using and leveraging open source is the determination of what, in their IP portfolio, is the unique differentiation between themselves and their competitors. What is, in other words, their “secret sauce.” Companies can then use open source to allow them, and their development, to focus on their secret sauce and to consume, or contribute/ donate, non-differentiating software to the open source community. This allows companies to focus their time, talent and resources on those aspects of technology that provide the most innovation to them and their customers.
Some companies, known as Open Core companies, also leverage the idea of “secret sauce” in that they release their code under an Open Source license, but sell “Enterprise Extensions” as commercial products, and keep that technology private and confidential, as their own secret sauce.
But the most important “secret sauce” in Open Source is also the most unrecognized and most misunderstood. Ironically, science fiction understands this secret ingredient better than most. It’s the delicacy specified in the Twilight Zone’s “How To Serve Man”; it’s the basic constituent of Soylent Green; it’s Arthur C. Clarke’s “Food of the Gods.”
Of course, with Open Source, what makes people the secret sauce is not their value as foodstuffs, but rather as the source of innovation, the catalyst of development. More so than anything else, Open Source has shown the ability for people to self-organize, in a collaborative, peer-based model to create projects and communities that serve as models of software development excellence.
Community Over Code
At the Apache Software Foundation, there is the motto of “Community Over Code.” The idea isn’t that the code doesn’t matter, but rather reflects a deep realization that long-term, viable, and secure software projects depend on a healthy community around it.
You see, you cannot really “create” a community in the same way that you create teams. A community is self-selected; a community is self-organized; a community is self-identified. A team, on the other-hand, is mandated. It’s an artificial construct, whereas a community is a natural one. Unfortunately, all too often these distinctions are lost or even ignored. Too many open source communities are hardly anything. It especially takes unique skills and drive for projects owned and directed by a singular corporate entity to really create and enforce a true community spirit. Because it is difficult for that to happen, you see many projects transfer over to a foundation to help nurture community development.
Open Source has shown the ability for people to self-organize, in a collaborative, peer-based model to create projects and communities that serve as models of software development excellence
Nurturing the community
In many ways, a successful open source project has direct parallels to a healthy biological eco-system. One key take-away when looking at it from this perspective is the absolute importance of diversity within that community. As the environment changes, and in the IT landscape it is changing constantly, eco-systems lacking in diversity simply go extinct. They lack the variation within that community to react to the new demands and successfully navigate the altered environments. That is other difference between teams and communities: communities reflect not only the individuals that comprise it, but also the environment and eco-system they exist in. For the communities to continue to exist there needs to be diversity which can continue to drive innovation and health.
There also needs to be parallels between open source communities and the engineering concept known as feedback loops. One reason why open source has succeeded is because it had allowed for an extremely tight feedback loop between the user community and the developer community. In many cases, those two communities, in fact, have significant overlap, and you can’t have a tighter loop than when your users and your developers are the same people. This brings home the point that for communities to have long term stability, there needs to be mechanisms in place, both infrastructural and social, which allows for end-users to become contributors; for people to become part of the core group behind a project. When there is no path for end-users to become contributors and then core project members, the community becomes stagnant, and the project itself suffers.
Open Source, and by extension InnerSource, reflects the understanding that the individual contributor is the primary source and driver of the success of the project. By creating a welcoming, nurturing and transparent environment, a healthy community can blossom. And healthy communities create the most reliable, robust and secure software possible.