You can choose from a range of quantitative and qualitative criteria for measuring an open source project, but there’s one thing they all have in common: The path to success, or failure, is by definition traveled in plain view.
"Building an open source project, much like any project, requires an understanding of the problems you are trying to solve for your users and a vision for how you will do so,” says Jonathan Katz, VP of platform engineering at Crunchy Data and a core team member of PostgreSQL Global Development Group. “The difference with an open source project is that the development of your vision occurs in public, and provides an opportunity for rapid feedback from a wider audience.”
[ New to open source software? Check out What is open source? at our sibling site, Opensource.com ]
Note that Katz didn’t say the feedback would necessarily be positive; he just said it would be fast, and visible to anyone.
Open source technologies don’t usually become valuable because someone’s just yawning out dribs and drabs of code in their off-hours and, voila, they’ve got the next Kubernetes. And the same principle applies to how IT teams adopt, integrate, and use open source in their organization. There’s plenty of real work and strategy involved.
And that strategy matters, since enterprise adoption has become so prevalent. In Red Hat’s 2020 State of Enterprise Open Source report, 95 percent of the nearly 1,000 IT leaders surveyed said that open source is strategically important; 77 percent expected enterprise open source use to continue growing.
[ Read also: 8 advantages of using open source in the enterprise.]
Elements of a successful open source strategy
With that in mind, we talked to open source experts to help you shape your approach. Let’s consider five important elements of a successful open source strategy, both from the standpoint of developing open source tools as well as adopting them as part of your overall enterprise IT portfolio.
1. You need the means for long-term endurance
The power to last is one of the biggest must-haves in open source strategy and execution, according to Ken Soh, a product engineer at AI Singapore and creator of the open source RPA tools TagUI and RPA for Python.
This is what separates sustainable projects from a forgotten GitHub repo with tumbleweeds rolling through it.
“You are dealing with a massive global market here with countless options for users to choose from, for free,” Soh says. “Without the ability to stay in the game, there is no chance.”
That ability can be derived from everything from personal passion to your employer’s sponsorship and support to VC funding or other external investment. You essentially need to answer the question: Who’s going to pay the bills for this? (Those bills can be both of the literal variety and of the sweat-equity variety.)
RPA for Python is a passion project for Soh that he maintains on the side, for example. TagUI, on the other hand, drew the interest and support of Laurence Liew, director of AI industry innovation at AI Singapore. “[Liew] believes in it and the rest is history,” Soh says. “He’s an early pioneer of open source in Singapore.”
2. Advocacy and adoption depend on clear outcomes
The value of an open source tool needs to be clearly connected to the problems it solves. This is true across different roles in the open source community, from creator or contributor to end user, as well anyone advocating the adoption of a tool within a broader team or organization.
You need to be able to answer the questions: Who is going to use this, and why? How does it help them? Compelling, cogent answers to these questions are part of the foundation for success. Otherwise, you’re pursuing a moving (or invisible) target.
“Advocacy for relevant projects and paradigms drives adoption in the open source community,” says E.G. Nadhan, chief architect and strategist, North America, Red Hat. “However, such advocacy must be for those projects that drive tangible outcomes for the ecosystem that the enterprise is part of. Ecosystems could be defined by the industry, business function, technology domain, business model, et cetera.”
3. Yes, you need a marketing plan
“Free” and “open source” don’t mean you get to ignore marketing. There is little to no “if you build it, they will come” magic here.
“Do not think for one moment that pouring significant resources to create an awesome free app automatically means it will gain traction with people,” Soh says.
There’s simply too much competing for the attention of potential users these days. And open source projects need people – not just users but active contributors and advocates.
“A good tool that nobody knows isn’t quite as useful as a sub-standard tool that many people start to talk about and use,” Soh says.
The flawed tool with lots of active interest is more likely to be improved by virtue of the fact that a growing community is talking about, using, and contributing to it. The flawless tool that no one knows about is the unheard tree felled in the open source forest.
Once you do build interest and momentum, it can have a cascading effect. Interest begets more interest, and there’s still no publicity quite like positive word-of-mouth, perhaps especially in the tech community. Evangelism is often also required for the successful adoption of open source tools inside your organization, even if someone else built them.
But people first need to know that the technology exists – and why it exists, per Nadhan’s advice above – and you have to start somewhere.
“During the early days of TagUI and RPA for Python, I cold-emailed thousands of users on GitHub that starred digital automation projects, to spread the word,” Soh says. “And I did that manually instead of using automation just so that I can know more about each potential user from their profiles.”
4. Develop clear feedback loops and documentation
Again, one of the distinguishing characteristics of open source development is that you’re essentially doing your work in public. Done right, that’s a good thing because a project can generate feedback and updates much faster, and in more organic fashion. But you’ll need a well-defined means for evaluating and acting on feedback for it to become valuable.
“To do this well, you need to have a solid process for incorporating this feedback in a way that complements the project vision,” Katz from Crunchy Data says. “Successful projects tend to find ways to encourage others to participate in the community through adoption and contributions, provide clear user documentation, and effectively promote the solution through various channels."
In Soh’s experience, rock-solid documentation is a crucial factor for long-term success and has a clear relationship with the kind of feedback that strong open source projects generate. If you’re a creator or key contributor, clear documentation is also an investment in productivity and sanity.
“If what you are creating is what people want, and you are giving it away freely, you are going to eventually get a lot of users coming to your project because it is both good and free,” Soh says. “But you can’t be spending a lot of time addressing user issues arising from poor documentation. That will only take away time that you can use for adding new features or fixing bugs.”
Soh says that he thinks he overall spent more time writing documentation for TagUI and RPA for Python than he did writing code.
“Good documentation that tries to cover commonly asked questions or roadblocks, without requiring a high technical bar to understand, means everyone wins,” Soh says.
5. Don't shortchange features
Offering an overly slimmed-down version of a commercial tool as “open source” tends to smack of marketeering; needless to say, that’s not the open source way.
This is becoming an increasingly important success factor as more and more commercial businesses launch or contribute to open source projects. Stripping all of the good stuff out of an “open source” component of a commercial platform isn’t a smart strategy. Companies and developers that “get” this tend to treat their open source projects – and contributions to open source projects launched by others – with the same or similar weight as their commercial products and services.
“Our open source projects are all intended to be useful, standalone tools in their own right,” says Liz Rice, VP of open source engineering at Aqua Security. “We also incorporate them into our commercial platform, where they become part of a much more sophisticated and interconnected system, but we don’t hold back features from the open source projects themselves.”
Rice points to kube-bench, which checks the security configurations of your Kubernetes deployment against the CIS Kubernetes Benchmark, as an example: It performs the same tests as Aqua’s commercial platform.
This is a chance to introduce yourself and your broader value rather than constantly hitting people with a hard sell. Again, remember Nadhan’s recommendation to think clearly in terms of outcomes; these are what create advocates for your technology or organization.
“Open source tools can be a really useful way to educate potential customers, especially in a relatively new and evolving field like cloud native,” Rice says.
Think of it as a way of showing the outcomes a particular technology can help produce, rather than simply telling (and selling) people that it can produce them. Users and teams new to containers and orchestration might not yet understand the importance of things like configuring Kubernetes properly for security or scanning container images for known vulnerabilities. In Aqua’s case, open source security tools like kube-bench and trivy are part of that education.
[ Want to learn more about Kubernetes Operators? Get the free O'Reilly eBooks: Kubernetes Operators: Automating the Container Orchestration Platform and Kubernetes patterns for designing cloud-native apps. ]
