Open-source software starts with developers, but there are other important contributors, too. Who exactly? Good question

Looking beyond the programmers

Is Linus Torvalds important to open-source software? Of course. Guido van Rossum, who created the popular programming language Python? Sure! Michael "Monty" Widenius of MySQL fame? Certainly. OK, what about Robert Love? Eben Moglen? Or Jono Bacon?

Who? Exactly. They latter three are, in order: the author of Linux in a Nutshell, arguably the most important Linux book; the leading open-source GPL attorney; and perhaps the top open-source community guru. Would open-source software exist without them? Yes. But, would it look the same? No. No it wouldn't.

We've always known that open source is more than its developers. Open source is also the people who document it, popularise it, organise the communities that support it and, yes, lead the companies that monetise it.

But, how do you measure their value? That's a good question without an obvious good answer.

For programmers, it's relatively easy. Once you get rid of the insane idea that programming productivity could be measured by lines of code (LoC) per day, like so many factory workers making widgets, you can come up with reasonable metrics.

These include a variety of Key Performance Indicators (KPI)s. These will vary from project to project, but once you've worked out what really matters in your programs, it's not too hard. Of course, KPIs can be abused. We're looking at you, Huawei, with some of your Linux "contributions."

My favorite metric, though, comes from Eric Elliott, author of Composing Software, who said: "The best way to be a 10x developer is to help 5 other developers be 2x developers." That's very open source in spirit!

But documentation? Legal help? Community development? There's no way to give those GitHub Stars. And they do matter.

As a Nature article recently pointed out: "Substantial contributions, such as organising meetings, providing outreach or performing other activities that leave no visible trace within the code, are often neglected. Indeed, some important contributions occur entirely outside of common open-source development platforms such as GitHub and often go unrecognised."

You think?

So, what to do? Well, the University of Vermont has joined forces with the Google Open-Source Programs Office into a project called Open-Source Ecosystems and Networks (OCEAN) to tackle the problem. Its job? Deepen our understanding of how people, teams and organisations thrive together in open-source projects and communities.

Their first goal is simply to figure out how to spot open-source contributors beyond the coders. It ain't easy.

The OCEAN crew is attempting to build a more inclusive picture of contributors to show what everyone brings to open-source projects. They're attempting to do this by looking at what communities are trying to accomplish.

These include maintaining healthy open-source software project repositories. That's not just having a GitHub. It includes supporting the program with good project management that avoids the bus problem – can the program survive its lead developer getting hit by a bus? Does it have maintainers who give good code reviews? Can its people triage bugs?

OCEAN also asks who the leaders are who actually, you know, lead the group – so that leaves the Free Software Foundation (FSF) out.

On the other hand, The Linux Foundation and The Apache Foundation seem to always find people who can actually organise programmers, writers and other contributors.

Finally, OCEAN is also looking for people who can actually bring people together into real communities, be they virtual or the increasingly rare real-life get-together. This includes leaders who can bring in people who don't all look, act and think the same.

Open-source organisations that consist solely of a God-King and his acolytes aren't healthy. OCEAN is looking for people who foster groups that are open to everyone.

OCEAN's end goal is "to normalise attribution for contributors to what communities think is important".

This isn't easy and they know all too well that they've just begun. So that is why they're seeking to work with and learn from open-source communities. Want to join in? Start here with the Open Source Contribution Schemas Workshop Series form.

Why bother? I will quote from Nadia Eghbal's Roads and Bridges: The Unseen Labor Behind our Digital Infrastructure: "The impact of digital infrastructure is still very difficult to measure. Usage metrics are either highly inaccurate or simply unavailable. This is not an easy problem to solve for. But without data about which tools are used, and how much we rely upon them, it is hard to paint a clear picture of what is underfunded. With better metrics, we could describe the economic impact of digital infrastructure, identify critical projects that are lacking support, and understand dependencies between projects and people."

I can tell that from where I sit – as someone who has been covering open source long before Bruce Perens, Eric S Raymond and Christine Peterson came up with the concept – this won't be easy. It's going to be a long, hard slog.

But the goal is worthy, and I, for one, would like to see more people recognised for the hard work and time they put into open source, even if their name will never crop up in a Git repository. ®

Source