Open source software starts with the developers, but there are other important contributors as well. Who exactly? Good question • The Register

0


Column Is Linus Torvalds important for open source software? Sure. 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. These last three are, in order: the author of Linux in a nutshell, arguably the most important Linux book; the leading open source GPL advocate; and perhaps the best guru in the open source community. Would open source software exist without them? Yes. But would it be alike? No no.

We have always known that open source is more than its developers. Open source is also the people who document it, popularize it, organize the communities that support it and, yes, run the companies that monetize it.

But how do you measure their value? That’s a good question with no obvious right answer.

For programmers, this is relatively easy. Once you get rid of the crazy idea that programming productivity could be measured by lines of code (LoC) per day, like so many factory workers who make widgets, you can get metrics reasonable.

These include a variety of key performance indicators (KPIs). These vary from project to project, but once you’ve figured out what really matters in your programs, it’s not too difficult. Of course, KPIs can be abused. We’re looking at you, Huawei, with some of your Linux “contributions”.

My favorite metric, however, comes from Eric Elliott, author of Composition software, who said: “The best way to be a 10x developer is to help 5 other developers to be 2x developers.” It’s very open source in mind!

But documentation? Juridical help ? Communautary development? There is no way to give these GitHub stars. And they matter.

Like a Nature The article recently pointed out: “Substantial contributions, such as organizing meetings, raising awareness or carrying out other activities that leave no visible traces in the code, are often overlooked. Indeed, some important contributions occur entirely. outside of common open source development platforms such as GitHub and often go unnoticed. “

You think?

So what to do? Well, the University of Vermont has teamed up with Google’s Office of Open Source Programs in a project called Open Source Ecosystems and Networks (OCEAN) to tackle the problem. His work ? Deepen our understanding of how people, teams and organizations thrive together in open source projects and communities.

Their first goal is simply to figure out how to spot open source contributors beyond coders. It is not easy.

The OCEAN team tries to build a more inclusive image of contributors to show what each brings to open source projects. They try to do it by looking at what communities are trying to accomplish.

This includes maintaining healthy open source software project repositories. It’s not just about having a GitHub. This includes supporting the program with good project management that avoids the bus problem – can the program survive its main developer being hit by a bus? Does it have maintainers that give good code reviews? Can its employees sort out bugs?

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

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

Finally, OCEAN is also looking for people capable of bringing people together in real communities, whether virtual or increasingly rare in real life. This includes leaders who can bring in people who don’t all look, act, and think alike. Open source organizations made up only of a God-King and his cronies are not healthy. OCEAN is looking for people who lead groups open to all.

OCEAN’s ultimate goal is to “standardize the attribution of contributors to what communities think is important”.

It is not easy and they know very well that they have just started. This is why they seek to work and learn from open source communities. Want to join us? Start here with the Open Source Contribution Schemas Workshop Series form.

Why bother? I will quote from Nadia Eghbal Roads and bridges: the invisible work behind our digital infrastructure: “The impact of digital infrastructure is still very difficult to measure. Usage metrics are either very imprecise or simply unavailable. It is not an easy problem to solve. But without data on the tools used and how much we rely on them, it’s difficult 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 lack support, and understand dependencies between projects and people.

I can say that from where I am – as someone who covered open source long before Bruce Perens, Eric S Raymond and Christine Peterson came up with the concept – it won’t be easy. It’s going to be a long, hard job.

But the goal is laudable, and I for one would like to see more people recognized for the hard work and time they devote to open source, even though their names will never appear in a Git repository. ®


Share.

Leave A Reply