How to partner with open source communities
By Natalia Levina
Over the last decade open source communities have become not just the bedrock of today’s digital industry, but also essential to some of the most advanced technology on the planet.
Or even outside the planet. The International Space Station (ISS) switched from Windows to Linux Foundation’s Debian operating system for its laptops in 2013 and NASA’s Robonaut, built to do some of the astronauts’ jobs on ISS, is run on Linux.
Tech giants like Google, Apple and Facebook have built well-established partnerships with the thousands of open source communities, while Microsoft, having been the focus of open source zealots’ ire for so many years, acquired the open source platform Github for $7.5 billion in 2018.
Microsoft may well have thought ‘if you can’t beat them, join them’ but for non-tech companies looking to enter this complex and diverse community, which has more than 500,000 software projects running on SourceForge, a development platform for the open source community, it can be a daunting and bewildering prospect.
Open innovation is a risky business, with firms used to building their own R&D labs closed-off from the prying eyes of competitors, to then invite anybody and everybody to help is a huge leap of faith.
But the tech giants’ innovations have come from collaborating with the open source community and using the ‘wisdom of the crowd’. Google has thousands of its employees embedded in the communities, working with them and feeding back the innovations that can improve and develop its search engine, while Apple does the same with its iPhone operating system.
The fourth industrial revolution and the exponential growth in data means every company has to consider itself a tech company now, the code for many machine learning models sit freely available on Github — how can any firm ignore that? But for the uninitiated, just how do you pick the right community to work with, especially when there are no legally binding contracts or any equity investment involved?
Reaching out to open source movement pioneers, we were able to conduct a rare empirical study of two of the multi-national tech corporations — sorry we can’t say which ones — leading the decade-long development of innovation partnerships with open source communities.
We interviewed 39 of the top managers and executives and analysed 150 internal documents to trace the steps, pitfalls, wrong-turns and ‘eureka moments’ to build a framework for guiding decision-makers on who to partner with in their open innovation projects.
Both multinationals engaged with close to 100 open source development projects and stated publicly that they had contributed more than 1,000 employees to these communities.
Initially, they were focused on taking the publicly available software from the communities and assessing how to incorporate it into their products and services. But the focus quickly shifted to partnering with the communities in co-creating innovations that would give them, not immediate, but long-term benefits.
They quickly learned they could not fully control the process or what was being innovated in the communities and often would be in the dark as to what would be produced when entering a partnership. Thus, they probed many communities through small scale endeavours to learn about them and to see how much potential there was in a deeper partnership before deciding which ones to fully go in with.
What our companies learned was that choosing which community to engage with ultimately depends on the company’s objective and its resources. From our research we are able to group these objectives into four general headings with metrics to assess a community’s suitability.
1 Adopting a high-quality, low total cost product
Firms may want to partner with an open source community to find cheaper and more efficient products to use in their organisation or to give to their customers.
Once a community has been found with a suitable product then the firm needs to assess how much value it can gain in terms of the savings it can make and the financial gain it will accumulate.
The number of developers involved in its development and testing, plus the number of downloads it has had already can be used as proxies for the product’s quality.
The diverse and transparent nature of open source communities means the quality of software innovations are often very high. As one manager said: “I believe that what makes [open source] special is what I call the copy modify, share cycle [of code development]. … This type of innovation might be better referred to as ‘diversity,’ because that is really what the great thing that you are getting is — the ability to follow lots of bets at once.”
Spotting which community has the highest quality products involves assessing the documents available, such as the availability of ‘how to’ Wiki pages, accessible FAQs, the level of detail in the community’s documentation and how quickly it was at updating them.
Also, how corporate-friendly are the open source community’s licences and is there the possibility to dual-license the software? Does the product have a track record of support from the community? This can be seen in the speed questions are answered and the average time it takes for issues to be resolved.
Are there any third party support costs for the product, such as what Red Hat does for several Linux services? Service support needs to be assessed as third parties will add to the cost, or does the community provide the updates and servicing?
2 Long-term product use
When the objective is to rely on the product being produced by the open source community for the long term, then it needs to be established that the community is actually viable over the long term.
That’s because the product will need servicing and updating by the community, so the community needs to be committed to maintaining it. Usually a commercial contract will specify the support services that the partner will give, but no such thing exists in the open source world. So how can a company measure a community’s long-term viability and health?
This can be done via a number of metrics that show it is growing and healthy, such as the number of people in it, how many contribute? Are these numbers rising or shrinking? How often does it release new software? How many bug reports does it issue, plus how quickly are they fixed?
A lot of this information can be sourced from the community’s page on Github, which can also show how many lines of code and subsystems there are — an indication of the amount of development going on — and the number of upgrade patches it has released.
While being on its mailing list allows a company to keep a track of who the key developers are making changes to the code and if there are a healthy number of new names coming through — participant turnover — to illustrate the community’s vibrancy.
Our companies also delved deeper into the community by participating with it to find out the amount of people testing the code and the number of responses to questions in its group.
3 Co-develop with a community
If the goal is to work with a community in developing an innovation together then how friendly the developers are towards corporations is key. Such a deep partnership needs to work on trust and the community’s ability to manage the project while keeping the company informed.
This is a difficult relationship to build as open source communities are traditionally reluctant to give up their independence, especially when it comes to the core source code of a software. This is the crown jewel for a community, so to allow a corporation in to fiddle with it is big leap of faith.
To assess whether a community will accept this it is important to understand the governance structure. If it mirrors the corporate world, with a hierarchy and clear communication lines, then there is more chance of being accepted — too much democracy can lead to paralysis. As one manager said: “You need some sort of executive decision-making capacity within the open community.”
The company can then reach out to this authority with more chance of a decision being made. Is there evidence of leaders making pragmatic decisions rather than ideological ones? Is there a history of infighting and ideological splits? This can be a warning sign. Also, how much control do the leaders have over the rest of the community?
Are communication and documentation transparent for the whole community? Are there clear and visible developers maintaining the source code? These are indicators of good governance, but to truly find out involves joining and becoming part of the community.
Indeed, the companies we interviewed often talked about nurturing their communities and guiding them to a state of good governance. This requires building trust by contributing developers, hardware and other resources to become a respected member of the community. By going this extra, deeper level of engagement a pipeline of high quality innovations can be secured.
4 Build the dominant ecosystem
By nurturing a partner community to become the biggest open source development platform, a company can not only benefit from a constant stream of high quality innovations but enhance its reputation with its customers and among the developer community.
The big open source communities like Linux are held in high esteem by software developers and seen as ‘pure coders’, who are interested in the challenge rather than the money. To become part of that scene may promote a company to Steve Wozniaki god-like status.
As one manager said: “As soon as customers found out that the code was based on open source technology, they trusted it much more because they didn’t have to overcome a mental gap of like ‘hey, what does (Company B) know about managing Linux?’ It’s no longer they trusted our offer, they’re trusting the community’s offer.”
However, it takes time and patience to build a healthy ecosystem, where other companies are not just tolerated but invited into the community. This helps to build network effects, where the community becomes more valuable as more people join it. The key metric to assess is the community’s ecosystem health.
How many other companies are involved? What are the quality of those partners and how much resource are they committing in terms of employees, hardware and code? How fair and equitable is the license regime of the software developed? Does the software code allow more partners to join? How many Application Program Interfaces (APIs) does the community have to integrate other software? Is the code available to every partner in the community or does one company control it and drive the agenda?
A healthy ecosystem governance tries to achieve meritocracy with clear rules over decisions and a good historical basis for those decisions. It also has an equitable distribution of decision-making roles rather than being governed by influence and cliques.
This can only be assessed by becoming part of the community and learning about others who are involved. As one manager said: “I’d really just look at numbers of commercial customers who are paying for services that are around the platform… And numbers of employees at companies whose job it is to provide that support.”
Useful information can be gathered by attending community conferences and getting a feel for how critical decisions in the past were made by its governance bodies (larger communities often set up a foundation governing key decisions).
Given their prominence in several such ecosystems, the companies in our study could have dominated key decisions, but instead they insisted on a proper meritocracy, so new members and a diversity of ideas could come to the fore. These are the sort of deep long-term relationships that Google has with Apache and Apple with the Linux Foundation.
For the uninitiated entering an open innovation partnership may seem daunting, but these four objectives can also be used as steps on the path to a deeper and ultimately better quality relationship. As the fourth industrial revolution unfolds this will become an imperative for most firms to thrive.
Further reading:
Shaikh, M. and Levina, N. (2019) “ Selecting an open innovation community as an alliance partner : Looking for healthy communities and ecosystems”, Research Policy, 48, 8, 103766.
Levina, N. and A.L. Fayard, “Tapping into Diversity through Open Innovation Platforms: The emergence of boundary spanning practices.” In Creating and Capturing Value Through Crowdsourcing, A. Afuah, C. Tucci, G. Viscousi (eds), Oxford University Press, 2018, pp. 204–235.
Lakhani, K., A.L. Fayard, N. Levina, and S. Pokrywa “ OpenIDEO” HBS Case #9–612–066, April 2012.
Fitzgerald, B., Kesan, J. P., Russo, B., Shaikh, M., & Succi, G. (2011). “Adopting open source software: A practical guide.” MIT Press.
Natalia Levina is a Distinguished Research Environment Professor and Professor of Information Systems at New York University Stern School of Business. She teaches Digital Leadership on the Executive MBA and Executive MBA (London) and lectures on Knowledge, Work and Innovation on the MSc Management of Information Systems & Digital Innovation.
For more articles like this sign up for Core Insights here.
Originally published at https://www.wbs.ac.uk on June 1, 2020.
