Can Open Source Sustain Itself without Losing Its Soul? – InApps 2022

At the end of 2021, the Log4j security vulnerability once again thrust the challenges of open source into the spotlight. This crisis birthed an “I told you so” moment for open source communities that are expected to consistently support and maintain projects with little (or, more likely, no) compensation at all, Mike Melanson wrote in his New Stack column.

But while the problems with open source persist, it nevertheless remains a fundamental part of many developers’ identities. For some, it has been a crucial part of their career trajectory.

“I literally wouldn’t have a career in web development if I hadn’t contributed to open source software,” Callum Macrae, a software developer and author of two books for O’Reilly (on jQuery and Vue.js), told InApps via email. “If I’d somehow found web development through another path, it would certainly look very different (and probably not as good) to the one I have now.”

Although Macrae is clearly passionate about the importance of open source for developers like himself, he is also skeptical about its future, at least from a maintainer’s perspective.

“I don’t think the current model of open source is sustainable for the people working on it,” he said. “It’s a model that relies on people giving more than they can for very little or nothing in return, and hoping that there will be someone to take over the mantle when the previous person burns out — and there usually is!”

The more “successful” an open source project becomes, the more strain it places on maintainers. And with open source now a fundamental part of the global economy, it’s unsurprising that the last half a decade has seen the emergence of initiatives designed to help those working on open source software, like GitHub Sponsors and Tidelift. However, the fact remains that the bulk of the work done on open source is unpaid.

OSPOs and Increased Professionalization

There are many people asking what can be done next. The growing number of open source program offices (OSPOs) suggests that businesses are becoming more aware of what open source actually is and what it involves.

Seventy-seven percent of organizations that have started OSPOs report that those offices have had a positive impact on their software development, according to a survey released in September by InApps, Linux Foundation Research and the TODO Group.

However, it’s important to note that the OSPO trend is still very new, with lots of room to grow. Thirty-five percent of respondents to the same survey that doesn’t have an OSPO said they hadn’t considered one, 28% said they don’t see the business value, and 19% said they’d never heard of them.

Those stats should provide a dose of realism and highlight the scale of the task before us.

But beyond questions about the extensiveness of OSPOs, the findings also force us to ask even more fundamental questions about the way open source is being encouraged and supported inside organizations. Statistics from September’s study warn that we could be moving backward:

• Forty-two percent of respondents said their organization’s engineers frequently or sometimes contribute upstream to open source projects, down from 48% in 2020.
• Thirty-six percent said they train engineers to contribute to open source projects, down from 42% the previous year.

This suggests that there is a disconnect between the growth of new mechanisms and institutions to support open source and the actual work being done. That might partly be down to the mismatch between commercial rhetoric and reality, but it might also be because the values and independence of the “movement” are disappearing.

“The fun parts have mostly gone away, but the pressures and expectations have increased,” Macrae said. How can the open source movement maintain its creativity and collaborative spirit while ensuring that the maintainers of essential software the world relies on have the support they need?

How Has Open Source Changed?

What it means to be an open source contributor or maintainer has changed in recent years.

In 2019, technology writer and researcher Nadia Eghbal noted in an essay for Increment how research from the latter part of the 2010s suggests open source communities weren’t consolidating but rather fragmenting. To a certain extent, Eghbal suggested, this is partly down to the nature of GitHub:

By standardizing version control, developer identity, and user experience, GitHub made it easier for developers to hop into any project and submit a contribution. As a result, projects now experience a greater volume of contributors, but many of those contributors interact with the project more superficially.

A 2016 study of popular projects on GitHub found that nearly half of all contributors in the sample only contributed once, accounting for less than 2% of total commits.

This evolution has resulted in a couple of different consequences. On the one hand, it has a technical impact.  While “smaller contributions [can be] valuable, larger contributions, such as new features, require longer focus time,” Patrick McFadin, vice president of developer relations at DataStax, told InApps.

But it’s not just about technology. If contributions are more sporadic and “superficial,” it isn’t a stretch to suggest that the sense of community that was once such an important part of contributing to open source projects is starting to dwindle.

This is something Macrae hinted at: “While most projects used to be community-led, it feels like they’re often backed by large companies now — the most obvious example being React/Facebook.”

This is a view that can all too easily be overlooked in a world where open source has now become another component in the business rhetoric of speed and innovation.

However, when you consider the world from which open source software emerged — antagonistic if not specifically political — it’s worth keeping in mind that there are some important tensions bubbling under the surface of the tech industry. Failure to address them could result in a more anodyne and less participatory future.

Open Source as a Place to Learn

Contributing to open source projects helps developers learn — and not just about coding, said Ana Jiménez Santamaría, a program manager at the TODO Group, an organization dedicated to supporting and enabling open source.

By contributing to open source projects, she said, “people not only have the opportunity to improve their code skills but also their soft skills, like learning how to work in collaborative environments.”

“I don’t think the current model of open source is sustainable for the people working on it. It’s a model that relies on people giving more than they can for very little or nothing in return, and hoping that there will be someone to take over the mantle when the previous person burns out — and there usually is!”

—Callum Macrae, software developer and O’Reilly author

Macrae’s early experience contributing to open source software underscores this point. “I’d never written PHP or HTML/JavaScript before, didn’t know what SVN and later Git was, didn’t have any computer science knowledge,” he recalled.

A crucial component in his learning was community: “I had a community who helped me learn, while also contributing towards something that thousands of people used.”

If we allow open source communities to fade, will they still be spaces where developers can learn? The answer might be finding better training and support elsewhere, whether that’s seeking out online learning resources or finding employment in organizations that demonstrate a real commitment to your skills and career.

But there’s something unsatisfying about that response: insofar as open source is participatory, the learning that happens there is, too. You’re not learning a curriculum or a checklist of skills; you’re learning how to build, fix, improve something alongside other people.

The Impact of DevRel

The growth of developer relations over the last few years could be viewed as symptomatic of the decline of “traditional” open source communities. It is also indicative of a greater awareness from businesses of the need to engage and foster communities around given tools.

As part of a data science master’s degree, Santamaría did research into the ways that DevRels worked within open source communities.

“The main goal was to create a model which profiles different kinds of developers, based on the activity performed through different channels,” she said, adding, “the business value from this analysis was to have a set of metrics that DevRel specialists can use to report their work through a community-centric model.”

This is undoubtedly interesting, but think how profoundly alienating this might have seemed to developers working in free software 30 years ago.

That’s not to say that any of this is particularly novel; community management is now part of the language of modern work in a variety of domains. Rather, it’s to point out that the way we think about “community” has changed from something that felt almost organic and playful, to something that can be organized in a way that can make it productive or more effective.

However, maybe the idealism that communities are somehow “organic” is precisely what has created many of the issues we see in open source software today.

“Open source is a community of communities and thus, it requires specialists that nurture and grow those communities as part of project sustainability,” Santamaría said.

“As open source adoption grows within organizations, I think the ‘open source’ DevRel profile is now key to one, educating developers to open source internally and externally and two, becoming the linchpin between the organization and the open source projects they care about.”

Interestingly, this model aligns with the way Eghbal believes open source has evolved, where a few maintainers are responsible for the bulk of work on a project. The industry is perhaps moving from mass participation to a culture of custodians.

This could be a good thing. But it also creates new questions: does this approach undermine true “openness”? Is it even scalable to meet the nature of the challenge before us?

Getting Started with Open Source

One of the benefits of bringing a DevRel model into more open source work is that it could help shape one of the trickiest parts of contributing to open source: simply getting started.

“Even though there are great guides and courses for beginners out there, there is no clear career path,” Santamaría said.

When there’s constant pressure to keep upgrading your knowledge to stay employable in a fast-moving field like tech, it’s no surprise that contributing to a project for no compensation isn’t at the top of many new developers’ agendas.

Arguably, we’re now in the worst of all worlds. Without the types of communities that Macrae found that helped him to learn programming, and without the more formal infrastructures of support that can help people navigate their way in the industry.

Arguably, we’re now in the worst of all worlds. Without the types of communities that many senior developers found that helped them to learn programming, and without the more formal infrastructures of support that can help people navigate their way in the industry.

Santamaría did, however, propose a few possible ways forward: A structured open source career path that involves “advocating for good open source practices for new generations,” and improving awareness of open source at a senior management level to “save developers’ working time to explore open source projects.”

The career path point is one noted elsewhere. In a blog post written in response to the Log4j story, Google developer Filipo Valsorda wrote, “you can’t start as a junior maintainer, get training and experience, and expect to eventually grow into a better paid senior maintainer. That’s not how any of it works today.”

Those sorts of changes will take time. In the short term, projects like First Contributions on GitHub can provide an onboarding ramp for people that want to get involved with open source.

The Role of Businesses in Open Source

It’s clear that businesses will need to play more of a role in open source. As Valsorda noted in the same blog post, “open source sustainability and supply chain security are on everyone’s slide decks, blogs, and press releases. Big companies desperately need the open source ecosystem to professionalize.”

Amanda Brock, CEO of OpenUK,  a not-for-profit that supports the use of open technologies, concurred: “We need to know not only that we have the best software that can be produced — which collaborative and diverse globally produced open source software is — but also that appropriate funding has been provided to ensure that those building all this essential software are able to maintain and support it being secure.”

Brock cited a number of examples of where this is happening in the U.K.; for example, she pointed to the work of the Energy Digitalisation Taskforce. That governmental group “suggested that the spine of the digitalized energy sector should be built on open source software. The National Health Service in the U.K. also now has an open source software-first approach for code it creates that it is increasingly trying to live by.”

However, while infrastructure projects adopting an open source approach to software are a clear endorsement of the model, they don’t necessarily fix the issues facing existing projects or support those responsible for maintaining them.

When the Commons Is a Public Good

It’s hard to disagree with Brock’s sentiment that we need “a shift from categorizing open source software in the commons to considering it a public good.” In some ways, however, the tragedy of the commons here is that we failed to recognize “commons” and “public good” might actually be one and the same thing.

The hope should be that open source remains a space for creative, independent-minded people to learn and explore while also creating something that can benefit everyone. If our solutions to open source sustainability undermine that core ethos then, really, what’s the point?

Featured image by Toni Reed via Unsplash.