Old projects and the free-software community

The Community Leadership Summit (CLS) is an annual event for community managers, developer evangelists, people who work on public-facing forums, and those with a general interest in engagement or community development for free-software projects. The 2016 edition was held in Austin, Texas the weekend before OSCON. Several sessions at CLS 2016 dealt with the differences exhibited between old and new free-software projects where community management is concerned. One of those tackled the problem of how to foster community around an older software project, which poses a distinct set of challenges.

Community revitalization

While there were a few plenary talks each morning at CLS, the majority of the day was reserved for "unconference" sessions: discussions on a topic proposed, on the spot, by a conference attendee. The "old projects" topic was raised in such an unconference session, moderated by Kate Stewart. Specifically, it dealt with how to re-energize a community around a software project that is no longer in the "new shiny thing" category.

Since the terms "old" and "new" are relative, establishing some context at the outset was important. It is often easy to attract code contributors, active volunteers, and enthusiastic members of the user community when a project is undergoing rapid development; doing the same thing for a stable code base or a core infrastructure project in "maintenance mode" is far more difficult. A few example projects were brought up at the beginning: FOSSology, which is well-established and has plenty of users but few developers; bzip2, which is a dependency of scores of other projects but is essentially in maintenance mode; and libexiv2, which is an under-the-hood library many end users may be taking for granted.

Each project's situation is a bit different, but they share common traits, such as a declining influx of new contributors and fewer volunteers actively staffing the communication channels. An Ubuntu developer noted, for example, that the excitement level of the Ubuntu community was quite a bit higher when the project was in "build a new distribution" mode; now that it is an established distribution, it is still popular, but the momentum has shifted to "building something on top of Ubuntu."

A few key facets of the community-engagement gap for older projects were identified in the discussion. First, established projects have a problem with the outside perception that there is little or nothing to do in the project—which is rarely actually the case. In the bzip2 case, for example, the project needs a number of infrastructure updates, including improvements to the build system.

Someone suggested that "creating a crisis" is often a viable approach to closing this awareness gap. Real crises, like the Heartbleed vulnerability for OpenSSL, have had that effect for some projects. But one can remind the free-software community as a whole how important an older project is by asking it to consider what would break if the project disappeared.

Another identified gap is that older projects may not have anyone working in the community-manager role, perhaps because that is a more recent idea. In the early days of the GNU project, one attendee pointed out, the other GNU developers were the user community. Because the broader free-and-open-source software movement has expanded so much since then, developers from those original projects may not feel a connection to the community even though they, as individuals, are not what has changed.

Another common factor is that end users often feel disconnected from stable or under-the-hood projects. In the FOSSology case, the project's users rarely mention its value in public, perhaps since it is generally an internal tool or used as an auxiliary to the user's main activities. It might reap dividends for the project to simply encourage its users to be more vocal about how FOSSology helps them, someone suggested. For library projects like libexiv2, the downstream projects depending on them can help connect library developers to the end users by making it clear how important the upstream project is, and perhaps by sharing community spaces and communications tools, such as forums.

Practical challenges

Communication tools and other community infrastructure can ossify if a project is not careful, which can have the unintended side effect of making it harder for new community members to get involved or, simply, to interact with the project's development team. In some cases, it may be that the project-hosting world has moved on: older projects may be relying on a SourceForge-hosted mailing list, for example, while many new users are familiar only with GitHub and the like. Updating the tools may be a painful, but beneficial, option.

A more difficult question is how to keep the project's communication channels up-to-date in light of the constantly shifting "tool of the month" culture. Several people mentioned the difficulty of maintaining Slack channels for open-source projects; Slack is proprietary, but the service is what new users—at least, at the moment—expect. There are mechanisms for linking a Slack channel to other (free-software) services, like IRC, but they seem to be difficult to use or in a poor state of repair. On the plus side, one attendee mentioned that it is quite easy to export Slack discussions as JSON and archive them online for wider access, a fact that seemed to come as news to many in the session.

Another issue is that the "maintainer" developers are usually not "creator" developers, who tend to drop away after a project becomes stable. Maintenance is frequently a side effort for someone who does other development; the divided focus and lack of creator's enthusiasm make it harder for a project to attract new developers. But there are publicity opportunities that are better suited to older projects than to newer projects. "Come to this project and have your work be used by 20 million people" was suggested; a core library could truthfully make such a claim while few newer projects could. But there are also recruitment obstacles more prevalent in older projects, such as technical debt, complexity, and reliance on older languages.

Yet, perhaps ironically, some of those technical issues can also make older projects a good target for education outreach. Several educators were in the session; they noted that when they talk to computer-science professors about getting students involved in open source, those professors are typically looking for older, stable code bases. Thus, they can have students work on small patches, and the experience can focus on the student's work, rather than wrestling with a shifting, chaotic project.

Those same attendees noted that professors also prefer establishing a long-term relationship with the project in question, which is beneficial to the project, too. The project gets a steady stream of contributions over multiple semesters, rather than a "drive-by contribution" from an individual summer intern who never returns. Few projects, they reported, have a point-of-contact person who can work with interested professors. Although getting college professors in touch with older projects would be mutually beneficial, the room seemed to agree, it ties in to the larger problem that open-source software has making inroads with the academic world.

That said, comparatively few long-established projects participate in efforts like Google Summer of Code or Outreachy. Making an effort to participate could be beneficial to those projects. Several attendees mentioned other outreach efforts that target bringing in new contributors, such as OpenHatch, CodeTriage, and Your First PR.

One attendee noted that perhaps some projects really do deserve to be moved to a "archival" type of project hosting. Older filesystems, for example, may no longer be used on newly set-up machines, but the code certainly needs to persist in the long term, since there will be users needing to access old disks and disk images long after the filesystem has been supplanted by a newer alternative. No one seems to address this project-hosting niche today; someone suggested that the Internet Archive, which performs a wide variety of archiving functions, might be worth approaching.

The session ended, as unconference sessions often do, only when time was up and the attendees ran off to the next round of discussions. But the mood of the room at the end was fairly positive. "Old" projects, it seems, may have to employ different strategies to attract vibrant communities, but it is certainly a challenge that the free-software community can meet. Some notes from the session are available online; those in attendance may continue to add to what is there, as may anyone else interested in the topic.