2020 was a year of extraordinary change, causing us to think deeply about our open source work, its impact and reevaluate what does and doesn’t work. While some areas of our lives may have slowed down, open source was not one of them. According to GitHub’s 2020 State of the Octoverse report, developers added over 1.9 billion contributions to various projects throughout the last year and individual developers made 25% more contributions to open source projects than in 2019.
Growth like this sounds great, but growth alone doesn’t equate to success. Success is tied to a clear strategy – your purpose, objectives and goals to help you determine if the growth you’re experiencing is headed in the right direction. It’s important to reflect on the overall energy and culture around your open source project to identify areas of improvement, prevent burnout and keep your community happy and willing to contribute. Read on to discover five tips to improve your open source strategy.
1. Take inventory
Before you can improve your open source strategy, you need to establish your starting point. Setting a benchmark enables you to measure change – whether good or bad. So, start by taking inventory: who in your organization is contributing to which open source projects? Which open source projects do your teams rely on to get their work done or their products built? What is the degree of dependency on those projects? In most cases the bulk of open source project contributions will be to third party open source projects as opposed to those your team created and released. But it’s important to understand which is which. This information will help you paint a clearer picture of your current open source activity and your reliance on selected open source projects.
“For the key projects your business relies on, broader involvement should occur in a coordinated and thoughtful manner. Are contributions by your team aligned with your corporate products strategy? What are your company’s strategic projects that key products rely on? Having a united front in the communities will help you to drive consistent and effective contributions.”
–Masae Shida, Senior Program Manager, VMware
2. ”Git” in order
Once you understand your open source portfolio, it’s time to get organized. For those projects originated by your team or company, determine what needs to be archived versus what should be dusted off and updated. Developers leaving a project is a natural process, but you should never abandon a repo, leaving no information about the project’s status. The orphaned repos set a poor example not only in the community, but inside your company as well. If a project lacks active maintainers, but remains open, put a note in the README that alerts potential users or contributors that the project is currently dormant. Otherwise, someone may file an issue or submit a pull request expecting a reply. According to Stefka Dimitrova and Ivana Atanasova, measuring project health is a key factor in managing open source projects and keeping things organized. When it comes to dealing with multiple projects, they recommend the following:
- Shorten the list. Archive or clean up any inactive projects so that you have better visibility of your portfolio.
- Group them by common criteria depending on the metrics you are applying.
- Use tooling to monitor all relevant metrics.
If you do decide it’s time to sunset your project, you’ll want to use the archive feature on GitHub, as there may be a number of people still using your repo. The Linux Foundation’s publication, “Winding Down an Open Source Project” provides some excellent tips. By organizing your portfolio, you’ll have a better grasp on how to manage and maintain your projects. And put a reminder on your calendar to review your portfolio every year. Once is not enough.
3. Business connections
Now that you’ve got everything in order, it’s time to face the hard part. For everything that you haven’t archived, can you articulate why and how the remaining projects are important to your business strategy? Dawn Foster does this by using data and metrics to tie back to her company’s current business goals. As one of the maintainers of the CHAOSS project, she spends a lot of time defining metrics that measure organizational affiliation, open source risk factors and diversity and inclusion—all which help companies know which communities and software to engage with, communicate the impact the organization has on the community, and evaluate the work of their employees within open source.
One of the best ways to ensure tight business connections with your project is to align your open source strategy with the overall business goals for your company.
“By having written documents that explain how your open source contributions support the goals of the company, you can help the executive team understand the importance of this work while also helping your employees understand how their day-to-day work contributes to the competitive advantage of the company.”
–Dawn Foster, Director of Open Source Community Strategy, VMware
A clear strategy with success measurements allows you to justify your open source projects to those making business decisions and enables you to continue to do great work in the years to come. However, if you’re unable to connect your project goals back to those of the business, that project is at risk of being on the archive list sooner rather than later.
4. Be inclusive
Open source is built on the premise of community. A project started in open source is a real-time example of collaborative innovation. But collaboration can only happen if there’s a welcoming community. That’s why it’s critical to knock down any barriers that could prevent people from joining your project, and consequentially hinder the project’s diversity.
From language to accessibility to project culture, make sure you are inviting everyone to the repo. Some of the terminology used in an open source project could make new community members — coding veterans, contributors and maintainers from other projects — feel alienated and discourage them from participating. That secret language only understood by seasoned contributors could be the biggest barrier to attracting new community members. Without clear, welcoming language, you’ll limit the community talent pool to the few who understand the internal “language” or vocabulary. Communication can also exclude another important audience of users and contributors: those with accessibility challenges. Follow best practices and accessibility standards to ensure you get the widest possible contributor community.
5. Make it easy
Look in the mirror: how easy is it to contribute to your project? Many people contribute to open source, in their “off hours” and it requires extra time and energy on their part. Help them out by offering clear processes that make it easy to start. Do you have a README, a Contributor’s Guide and a good first issues list? Contributors typically look for these items before opening an issue or a pull request, so don’t keep them guessing! Nisha Kumar says, “Open source contribution is not a technical interview. New contributors are also new to using tools like git and GitHub. Maintainers who understand that can offer valuable avenues to learning.” Clearly communicating important project information enables prospective contributors to quickly become productive members of your open source community.
Here’s a quick checklist to ensure you have the basic elements to welcome new contributors or users to your project:
- README: clear, concise with explanations of project’s purpose, ideal users and use cases, and the problems it solves. Octant, a VMware-originated open source project, boasts a very comprehensive, but easy to read README file –take a look.
- Contributors Guide: instructions for anyone who might want to contribute; this should include information on best practices for pull requests, how to file issues, etc. For a good Contributor’s Guide look no further than Tern. With its helpful list of prerequisites to its tips on how to file a PR, this guide helps a newcomer get started quickly.
- Governance: describes how the project is governed: when do the maintainers/contributors meet, how code reviews are conducted, and any other operational details. Dawn Foster shares her thoughts on governance and the TODO group also offers some excellent ideas on best practices. Project Velero offers an example of a well-documented and clearly explained project governance file.
- Good First Issues: once those three documents are complete, take the next step and create a good first issues set. Better still – tag your issues clearly: what’s suitable for a beginner to advanced contributor; what’s on the roadmap, and what’s technical debt. The Tern maintainers do a good job with tagging issues. These curated starting points form ideal on-ramps for new and seasoned contributors alike. And remember, that not all project contributions are code – documentation and project management are two areas where just about every project could benefit.
Strategize for Greater Success
A project or a program without a strategy can only drift. Reaching a desired outcome requires a strategy and defined goals. Every project or program needs a strategy, so if yours is outdated or lacks detail, the time to change that is now. Start by taking inventory and then cleaning house. Next, ensure you understand the connections back to the business. Also, make sure that your project welcomes contributors of all skill levels and backgrounds, essential to increasing diversity and growing a vibrant community. Finally, make sure that your project is well-documented with clear guidelines on how to contribute. Taking these five steps will help infuse your open source projects or programs with new life and put them on a strategic road to success.
For more information on improving your open source strategy, stay tuned to the VMware Open Source Blog and follow us on Twitter (@vmwopensource).
