Your open source project is one of thousands, so how do you help its community grow? Start with project management, great documentation, and a road map.
At LinuxCon North America, held September 16-18 in New Orleans, community manager Lars Kurth presented a case study that showed how the 10-year-old Xen project regained community support with the help of better project management. Granted, Xen also became a Linux Foundation Collaborative Project in April 2013, but Kurth explained how support for the project dwindled over the years because it lacked a few things that make community participation possible. If your project needs to gain traction in the open source community, lessons learned in the Xen project might be just the ticket.
Xen is an open source hypervisor with more than 10 million users, and it powers big-name clouds, including Amazon Web Services and Rackspace Public Cloud. Xen started as a research project at the University of Cambridge in 2003. In 2007, Citrix bought XenSource, Inc., which supported the project. Now Citrix supports the free, open source Xen software, and also sells enterprise versions.
Kurth says that Xen was a “messy teenager” for the first 10 years of its life. The project had unwritten rules and undefined roles, lack of upfront collaboration, and no rules for how to be a maintainer or a committer. The project didn't have a road map until about a year ago. The result was that joining and working with the project was difficult for would-be contributors, and large, more mature vendors — including Canonical and Red Hat — dropped support. From 2005 until 2007, project growth was flat, but then KVM (Kernel Based Virtual Machine) came along and Xen vendors started bailing.
As Kurth says, the Xen project needed to grow up.
Kurth joined Xen in 2011 and the project started documenting rules. In 2012, the newly named technical coordination team created a roadmap and release management. And then the Linux Foundation got involved.
Being a Linux Foundation Collaborative Project has benefitted Xen because the project is now “part of the Linux family rather than outside,” which has led to a number of changes. “For example, when we add a new feature to Xen, now feedback and discussion is fact-based and usually constructive,” Kurth says. Before Xen became part of the foundation, Kurth says, many people in the Linux community favored KVM. “The thinking really went along the lines of: KVM=Linux=Good. Xen=Citrix=Bad.” With the open source community connecting Xen with Citrix, the project's features and open source nature were overlooked. Kurth says that Xen's new role as a Linux Foundation Collaborative Project has changed how the community and press view it.
“Of course, there are many other benefits,” admits Kurth. “The Linux Foundation has a vast network of vendors supporting Linux. Being part of the Linux Foundation means that it is a lot easier to have conversations, some of which lead to collaboration and other projects.” Kurth notes that this is particularly evident around ARM support in Xen, where the project is starting to see first signs of collaboration with mobile and automotive vendors who are part of the Linux Foundation.
The Linux Foundation also provides advice on how to run a project, including PR, marketing, governance, and legal issues. Also, there is cross pollination between projects. “I frequently have conversations with other projects along the lines of 'I have problem X — how do you tackle it,'” Kurth says. Working with new resources has helped Kurth better manage the Xen community, too. “In the year I have worked with the Linux Foundation, I learned an awful lot,” he says, “which is also helping the project hugely.”
Almost all open source projects can benefit from better documentation. “Documentation is one of those areas that is often left behind; it’s just not sexy enough,” Kurth says. The Xen project now holds monthly Documentation Days, where developers and users come together and improve documentation. “But there is always a gap, and there is always more developer activity than user activity.”
Although project documentation is vital, Kurth thinks governance and process is more important. “I don’t mean process in terms of 'procedural red tape,'” Kurth says. In fact, he prefers as little process and governance as necessary. Rather, having a process is about expectations setting. “It must be clear for somebody who joins the community what they need to do to achieve a certain goal. So, for example: How do I become a contributor and later maintainer? What steps do I need to go through to become influential in the community? Or, how are decisions in the community made and conflicts resolved?” Answers to these questions should all be found easily in project documentation.
Lacking a roadmap doesn't mean that your project won't succeed, however. “There is no roadmap for the Linux kernel and it prospers,” Kurth admits. “The same is true for Python and other projects,” he says. But Kurth wonders whether these projects could be even more successful if they had a roadmap. If commercial products are built on top of your project, though, a roadmap becomes more important. “Not having one makes it hard to build products on top of what your project creates.”
If you don't already have someone in your project who is working on documentation, you have a great opportunity to reach out and grow your community. Increasing diversity in openvsource contributions was also a hot topic at LinuxCon, and documentation is a great way for a new contributor to get started. Not only will the new community member help improve the project by documenting it, they will be making it easier for the community to continue growing.
See also:
[dfads params='groups=932&limit=1&orderby=random']
[dfads params='groups=937&limit=1&orderby=random']