Author: Shane

I’ve been reading papers on “sustainability” frameworks of shared definitions, and was struck in many of the sections on Stakeholders. We think about the various FOSS projects, about the big industry players, about the rest of the user base commercial companies, and even about public policy. And yes, we do talk about “pay the maintainers”, and there are several organizations solidly devoted to that problem.

But what about volunteer individual coders as a class?

Much of open source contribution is done in small chunks by individuals “scratching their own itch” to fix a bug or add a new feature they happen to need. While some of this is done in conjunction with a job or a college class, some of it still done just because the coder wanted to get it done, not necessarily to get paid or a better grade.

A poor definition of this class is “everyone who’s contributed to open source without directly getting paid for it”, which doesn’t help much, but does give perspective on the scale. And most people working in software are likely to go back and forth from paid work to some kind of volunteer work (either piecemeal fixes or as part of a larger effort) many times in their career.

How can we classify all these individuals?

• Software industry career workers, who will likely have many different roles in a career. They may sometimes lead projects, and often will make significant investments over time. They may often have a holistic perspective on FOSS components in relation to their business, so often are very conscious of what they open source, and what is proprietary.
• Software industry-adjacent workers, who will work on specific bugs or features their industry needs from time to time, but primarily focus their work on custom features internally (i.e. possibly not contributions).
• Academic, scientific, and policy/government workers who build software. When they open source something – depending on institution policies – they are more likely to be careful to ensure an entire package is included, so that their work can be easily reproduced elsewhere.
• College and high school students looking for learning opportunities or connections in industry. Only part of the driver here comes from curriculum; much of the drive likely comes from where the students first feel they can make contributions and get some feedback or recognition.
• Hobbyist hackers who have a passion for their work. Yes, they still exist, although it’s certainly a rare individual here who truly drives an entire project these days. But where hobbyists show up, they can be an important part of maintenance and quality control. Hobbyists are likely software industry professionals who truly do open source at night, separately (in some cases deliberately) from their day jobs.
• Who am I missing? I know there will be a handful of other sub-groupings that could be useful to consider tracking.

What messaging can we use to encourage individuals?

These groups are obviously quite diverse in other characteristics, and include millions of people, so it’s difficult (except perhaps in public policy spheres over years) to directly influence them. But we certainly need to include this concept in discussions about sustainability.

One potentially practical task is to find ways to promote messaging that can continue to inspire newcomers to open software (or science, or government!) that yes, it is important they contribute, even in a small way. Helping FOSS organizations, projects, and communities find even slightly shared ways to both be friendly, to explain how to do things in their world, and to provide the general encouragement to newcomers seems like a useful practice area to help nudge the actual FOSS world into better sustaining itself.

Reading about open source sustainability the past few weeks, I’ve been trying to find some pithy and useful quotes to start building out my FOSS Sustainability website. I started with a listing of the obvious resources – key funding sources, some overviews about how governance and funding mesh (or don’t), and the like. But between reading industry blogs and scratching the surface of research papers on sustainability, I haven’t found great answers yet. What have I found?

More questions.

Sustainability as a concept around open source projects and communities is such an overloaded idea that I’m having a hard time finding a specific place to start. So instead, let’s start with a list of some focus areas and questions to ponder, in terms of what perspective or audience we’re starting with. Thankfully, I’m also finding out many other folks are in the same boat, and are working on figuring out how to define this in broader, more useful ways.

Who is our primary focus?

The obvious group are “Pay the maintainers”, individual coders managing widely-used independent projects. The flip side are enterprises – who might pay for the projects they use, and various funding organizers: either grantmakers, collectives working on pooling and releasing funds, or even simple sponsorship buttons you can put on your repo.

The other kinds of maintainers are in community-governed, foundation-based, or corporate-sponsored projects. Plenty of projects are written by a combination of paid employees by one or more leading corporations, plus a constellation of individual coders or smaller companies.

The enterprise perspective is an entire universe of it’s own: often the people who understand the value of software they use are disconnected from people who control funding or strategy in a company.

Governments, NGOs, standards bodies, and the like are another universe of people concered about sustainability. Their perspectives are starting to get broadened by the growning research about both FOSS software impacts, but also risks, security, supply chain issues, and all the other news we read about lately.

Oh, and of course end users.  Where do they fit in with sustainabilty? Does the average user even understand they’re using open source inside whenever they touch a smartphone or computer?

What kinds of sustainability do we mean?

How do we keep open source software secure? Heartbleed’s giant security scare eventually turned into Core Infrastructure Initiative, a foundation to help fund quality and development of OpenSSL. But what about security across the hundreds of other critical projects used everywhere?

Are we concerned with keeping certain kinds of projects alive and self-managing and making bugfixes? Or are we concerned with the core infrastructure bits that everyone uses, and keeping them as solid upstream projects – instead of one particular vendor simply making all the fixes to their version, which becomes the de facto one most folks use?

How about long-term sustainability of the code itself, physically? How long are archives guaranteed, will they be findable, include history and releases?

How about keeping tooling current to today’s versions of other software bits in the dependency chain? Is there anyone around who can even recompile Tool X that uses frequently updated Dependency Y to ensure the binaries work correctly?

Of course all these questions might be changed subtly depending on the programming languages, and how projects are architected – or documented. The kinds of long-term tweaks to a UNIX utility are very different than a bit of Java middleware.

Does money come into it?

It’s more difficult, but you can find ways to make some projects sustainable without throwing money at them. But in most cases, we need someone to make a financial investment. And while sharing code has zero cost across any sort of boundaries, sharing financing and legal relationships (of employees, contractors, service providers, or whatever!) have significant costs – and lots of asymmetry in terms of knowledge and capacity to manage transactions – or even know they could ask for transactions (or some funding).

Which organizations are we considering?

Software companies (who build something related here) behave differently than other companies. Enterprises have very different resources and constraints than midsize or smaller companies. What about nationality and local law factors in how companies use or maintain their software dependencies?

By now you can see my theme: each of these general topic areas has a whole host of sub-topics, many with very different concerns even when they might seem similar. And of course the real world is a matrix of matricies of relationships between the who, the what, the money, and the how.

Feeling a little overwhelmed? I’m right there with you. Thankfully, that’s one of the exact questions some smart folks are thinking about right now: how can we define “sustainability” with some concrete concepts and shared terms / categorizations that we can all understand and agree on?

We’ll see! But I’m meeting some people that are making this very, very interesting to work on!