The open-source generation gap

At the 2016 Community Leadership Summit (CLS) in Austin, Texas a pair of sessions discussed the culture gap that exists between a substantial contingent of old and new open-source developers. The first session sought to understand the background of the divide, in particular to understand why a large proportion of new developers seem to have no interest in licensing, simply wanting to work "in the open" and skip over the other details. The second session sought to figure out how the divide could be bridged.

Both of the sessions were of the unconference variety, meaning that they were proposed, organized, and moderated by one of the attendees. In fact, the first of the sessions originally proposed to tackle solutions as well; it was only when time ran out and the discussion was nowhere near a resolution that the second session was proposed to follow up. Unlike the session dealing with older software projects, this discussion centered around what is apparently an age-based divide between different "generations" (for lack of a better term) of open-source developers.

The impetus for interest in the topic was a widely circulated Medium post by Nadia Eghbal, in which she decries the term "open source" as irrelevant. Among other things, Eghbal's post contends that most developers don't know that there is a formal definition of "open source" and that most developers don't care about software licenses (much less whether they happen to align with someone else's definition). What really matters to modern developers is "1) building and 2) collaborating in public." She proposes the term "public software" as a replacement that more accurately captures the important issues: that development is a visible process and that the product (be it code, data, or anything else) is accessible to anyone.

Mind the gap

As one might anticipate, that position frustrated many people who work in the open-source software world, particularly those involved in licensing work. In the first unconference session, moderated by Spencer Krum, an effort was made to suss out where the root of the disconnect lies, since it is clearly a trend among newer developers. Part of the problem, it seems, is that tools built by the open-source (and free-software) community have now become widely available to developers who are not motivated by the ideals of those movements. GitHub is a prime example; although it is built on Git and makes it easy to use workflows that grew out of the free-software movement, anyone can use it for almost any purpose.

Meanwhile, online collaboration tools have become more "frictionless" as time has gone by. Consequently, older projects that place a heavy emphasis on GPG-signed releases and an email-driven patch review process have stuck with one generation of tools, while newer projects have picked up a newer generation of tools like GitHub's web-based issue tracker. So there is a practical disconnect, which is then exacerbated when people say (as one attendee put it) "we do things this way because that's what Linus does."

Others suggested some blame belongs to the prominent organizations. The Linux Foundation, one person said, tries so hard to say "you don't have to worry about licenses and patents if you work with us"—in an effort to attract developers—that the importance of those details gets lost. Another noted that the Open Source Initiative (OSI) coined the term "open source" in the first place and thus holds the responsibility for letting it devolve into a generic term (as Eghbal's post contended).

OSI General Manager Patrick Masson was one of the session's attendees, and he pushed back on that last point. There is too much "open-washing" these days, he said, but it does not come from the OSI. There is still only one Open Source Definition; the dilution of the term comes from others who use "open" to describe organizations, workflows, processes, and other things unrelated to software licensing. "We have open hardware and open data, but also 'open cola' and 'open beer.' That blurs over an important distinction. Not everything fits."

Several others agreed with Masson, noting that misunderstandings about the importance of licensing belong not to the institutions, but to the individuals not giving enough thought to licensing issues. As Deb Nicholson put it, much of the legal framework of free software and open source has developed to fit intellectual property law. "Saying 'we don't care about licensing' is fine—until Oracle v. Google hits you."

A number of people felt that the new-contributor experience of projects was responsible for much of the gap between generations of developers. If a project says "follow these seventeen steps and then we'll accept your contribution," for example, quite a few potential developers will simply walk away. Another attendee added that the concern is not so much that projects have put up barriers to entry, but that there is a big difference between the ease of joining an established open-source project (such as the process for becoming a Debian Developer) and the ease of starting a new project of your own (such as pressing the "new repository" button on GitHub).

That led several to suggest that the OSI should provide guidance on contribution models, contributor agreements, and similar facets of the development process. Masson politely disagreed, as did several others. One noted that just as there is clearly no "one true license," there is no "one true contribution model." Perhaps, though, the community needs to do some work to determine which parts of the contribution process are essential to open-source development and which are not.

Quite a few other discussion threads came and went during the session. For example, it was noted that the majority of the people using GitHub are individuals, not projects. Many seem to use GitHub solely to store personal project files they have no interest in promoting to the public. Many others have a habit of forking existing repositories rather than collaborating. Consequently, the oft-cited statistic that most GitHub repositories have no license is misleading. Another person suggested that part of the divide comes from the fact that so many new projects are web-development efforts and software-as-a-service (SaaS) projects. There is an inherent gap between how those projects approach licensing and how non-web projects approach licensing.

Close the gap

The follow-up session about the open-source generation gap came the next day. Many of the attendees from the previous session returned; Nicholson acted as moderator. To start things off, she noted that most of the people at CLS (and certainly most at the session) fell into the "older" generation, but that it was important to recognize that there was work to be done on both sides. That said, there was a show of hands, and several people in the session self-identified as being part of the "younger" crowd.

A number of people felt that the disconnect over the value of software licensing indicated that the older generation had not been doing a good job of connecting incoming contributors to the necessary background material. The older generation needs to better document and explain the history of the free-software movement for new community members.

Along those same lines, several people felt that individual projects do a poor job of documenting the decisions that led to their current architecture and development practices. Consequently, new developers can get turned off by what they perceive as poor design, only to join newer projects that eventually make the same kinds of decisions as they mature. Explaining the "whys" of a project makes it easier for newcomers to get involved.

As an example, one attendee, who works at a large online retailer, noted that the company had routinely encountered such an attitude from its new hires, who were appalled to learn that the company's system architecture is a convoluted mess and want to try and redesign everything from scratch. So the company added a session to its new-employee orientation process, during which a senior engineer lets the new hires work through their own architectural decisions to design a system that handles all of the company's services. They learn to appreciate that services can start simple, but grow in complexity, and come away with a better understanding of the overall architecture.

Another suggestion was that established projects need to meet new contributors "where they're at," even when that entails leaving the project's comfort zone. Jenny Wong noted that the WordPress community has started holding "new contributor day" events, at which the experienced contributors meet with the newcomers and, together, work through the new-contributor documentation that the experienced folks themselves have written. That lets the two communities work together, and it lets the experienced coders see firsthand what struggles the new contributors encounter—including, notably, where the new-contributor documentation is falling short. Other attendees concurred that having "onboarding" documentation was important, but that it was equally important to encourage bug reports and patches to that documentation from new contributors as they work through it.

Among the other points raised during the session, attendees noted that it was important that the community distinguish between minting new project contributors and minting new free-software activists, and that it was important for projects to put a check on flamewar-style debates—particularly those that focus on dismissing certain technologies. It is easy for experienced developers to become attached to a language or framework, but there will always be new languages and projects popping up that are the entry points for new coders. Project members deriding language Y because it is not language X may only serve to tell newcomers that they are not welcome.

Time elapsed in the second session well before the attendees had finished sharing all that they had to say. While there were plenty of thought-provoking points raised, this is sure to be a topic that the community continues to debate for some time to come. It will be particularly interesting to see how different subsets of the open-source community view the issues, since other samples might have different takes than those found among the CLS 2016 attendees.