How can you grow an open source community? Two blog posts from The Document Foundation (TDF) illustrate a proven double-ended strategy to sustain an existing community. Spanish
Since it was established in 2010, the LibreOffice project has steadily grown under the guidance of The Document Foundation (TDF) where I’ve been a volunteer — most lately as a member of its Board. Starting from a complex political situation with a legacy codebase suffering extensive technical debt, TDF has been able to cultivate both individual contributors and company-sponsored contributors and move beyond the issues to stability and effectiveness.
What made the project heal and grow? I’d say the most important factor was keeping the roles of individual and company contributions and interests in balance, as these two posts illustrate.
The first priority for growth in any open source project is to grow the individual contributor base. TDF has used a variety of techniques to make this possible, many embodied in first of the two illustrative posts, announcing another Contributor Month declared for May 2017 which asked people to:
- Help to confirm bug reports
- Contribute code
- Translate the user interface
- Write documentation
- Answer questions from users at ask.libreoffice.org
- Spread the word about LibreOffice on Twitter
As part of the event the co-ordinator promised to send specially-designed stickers to all contributors, providing a positive reinforcement to encourage people to join in and stay around.
Equally importantly TDF provides introductions to many contribution types. There is a well-established getting started guide for developer contributors, including the well-established “Easy Hacks” list of newbie-friendly things that need doing. There’s also a good introductory portal for translators/localizers.
All of this has been undergirded by sound technical choices that make joining such a complex project feasible:
- Reimplementing the build system so you don’t have to be a genius to use it
- Extensive use of automated testing to virtually eliminate uncalled code, pointer errors and other mechanically-identifiable defects
- An automated build system that stores binaries to allow easy regression testing
- Translation of comments into English, the project’s language-of-choice (being the most common second language in the technical community)
- Refactoring key code to use modern UI environments
Secondly, TDF has operated in a way that encourages the emergence of a commercial ecosystem around the code. That in turn has led to the continued employment of a substantial core developer force, even in the face of corporate restructuring.
LibreOffice has a very large user base — in the double-digit millions range worldwide — and many of those visiting the download page make financial donations to help the project. That’s a wonderful thing for a project to have, but it turns out that having money is not necessarily an easy blessing. It needs spending, but that has to be in a way that does not poison the contributor community.
Rather than hiring staff to work on the software, the project identifies areas where unpaid volunteers are not likely to show up and its Engineering Steering Committee proposes a specification. The Board of Directors then creates a competitive tender so that individuals or companies can earn a living (and gain skills) making LibreOffice better while still retaining the collaborative spirit of the project. Doing this builds commercial capability and thus grows the overall community.
So the second post is a sample tender, this one to do some unglamorous refactoring work to update the SVG handling. TDF is likely to receive a number of costed proposals and the Board will make a decision how to award the work based on the greatest community benefit — a combination of optimum cost, involvement of community members, nature of the bidder and more. The result is a community contributor fairly compensated without creating a permanent TDF staff role.
Balance Yielding Benefit
As a result of this and other carefully-designed policies, the LibreOffice project now has a developer force in the hundreds, companies whose benefits from LibreOffice lead to them making significant contributions, a reworked and effective developer environment with automated testing to complement the test team, and one of the most reliable release schedules in the industry. This means new features get implemented, bugs get fixed and most importantly security issues are rapidly resolved when identified.
This is what OpenOffice.org became when it left the commercial world. The early controversies have passed and the project has a rhythm that’s mature and effective. I think it’s actually better now than it was at Sun.
(This article was made possible by Patreon patrons. Become one!)