let’s hear it for the maintainers!

A couple of weeks back Anne Johnson pointed me at a new report from the Ford Foundation – “Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure.” Written by Nadia Egbhal the report examines the surprisingly unsupported foundations of much of the infrastructure we rely upon.

“Nearly all software today relies on free, public code, written and maintained by communities of developers and other talent. This code can be used by anyone—from companies to individuals—to write their own software. Shared, public code makes up the digital infrastructure of our society today.

Everybody relies on shared code to write software, including Fortune 500 companies, government, major software companies and startups. In a world driven by technology, we are putting increased demand on those who maintain our digital infrastructure. Yet because these communities are not highly visible, the rest of the world has been slow to notice.

Just like physical infrastructure, digital infrastructure needs regular upkeep and maintenance. But financial support for digital infrastructure is much harder to come by.

In the face of unprecedented demand, the costs of not supporting our digital infrastructure are numerous. No individual company or organization is incentivized to address the public good problem alone. In order to support our digital infrastructure, we must find ways to work together.”

https://twitter.com/nayafia/status/757655696699555840

Many of the open source projects and modules we use every day are maintained by one person – and that person likely spends a lot of their time being abused for the privilege. Open source consumers are generally quite a demanding and yes entitled bunch.

It is all too easy when you’re a consultant like me, or a developer working at a well funded startup, to imagine that everyone gets paid to create and sustain open source projects. At RedMonk after all we built a company that gets paid advising people to do just that. And yet. My business partner Stephen O’Grady wrote a book called The Software Paradox, examining the fact that while software becomes ever more valuable, companies are increasingly unwilling to pay for it – software license sales at major companies are trending to zero. Instead of selling software licenses and maintenance fees companies must build businesses on services and data.

We live in a world when tech vendors, web companies, VCs and startups all support open source projects. So everything is fine, right? Not so much.

I mention maintenance for a reason – it’s notable that in the age of cloud based services we see maintenance fees as some kind of absurd retrograde mark of the old school. OMG remember when software companies used to charge for maintenance??? How lame. Legacy technology sucks. Things are so much better now.

But maintenance has a cost. Of course it does. Because maintenance has value. Because maintenance requires labour.

That’s the beauty of Egbhal’s report – it makes the analogy of roads and bridges – if we don’t invest in maintenance then they collapse.

Andrew Russell wrote a fantastic post – Hail The Maintainers – that gets right to the heart of it.

“Innovation is a dominant ideology of our era, embraced in America by Silicon Valley, Wall Street, and the Washington DC political elite. As the pursuit of innovation has inspired technologists and capitalists, it has also provoked critics who suspect that the peddlers of innovation radically overvalue innovation. What happens after innovation, they argue, is more important. Maintenance and repair, the building of infrastructures, the mundane labour that goes into sustaining functioning and efficient infrastructures, simply has more impact on people’s daily lives than the vast majority of technological innovations.”

I wish I had known about his conference The Maintainers – How a Group of Bureaucrats, Standards Engineers, and Introverts Made Technologies That Kind of Work Most of the Time.

The maintenance problem is not just about software. Capitalism itself is terrible at maintenance. We’re so busy talking about and investing in “innovation” that we forgot the foundations need to be built and maintained. Witness the current fetish for “disruption” as a good in itself.

But I don’t see Uber building roads. Elizabeth Warren got it just right:

“There is nobody in this country who got rich on their own. Nobody. You built a factory out there – good for you. But I want to be clear. You moved your goods to market on roads the rest of us paid for. You hired workers the rest of us paid to educate. You were safe in your factory because of police forces and fire forces that the rest of us paid for. You didn’t have to worry that marauding bands would come and seize everything at your factory… Now look. You built a factory and it turned into something terrific or a great idea – God bless! Keep a hunk of it. But part of the underlying social contract is you take a hunk of that and pay forward for the next kid who comes along.”

I have sat through seemingly hundreds of presentations over the years where vendors explain that IT is broken because it spends too much on maintenance, and not enough on innovation. Consulting companies love to show off the innovation to maintenance pie chart to chide the customer into doing something new.

I have covered mainframe technologies for more than 20 years now, and they were already considered dead when I started doing so. But legacy just means in production. It just means creating value. Here are some thoughts from legacy boy.

Don’t get me wrong – I am certainly not claiming that everything old is good, that every production system should be left as it is. On the contrary – continuous deployment is all about building maintainable systems that stand up to the rigours of production and can be changed and maintained over time.

But understanding the value of the maintainers means taking a broader view, touching on many of the critical social issues we face in open source. Thus for example we celebrate the coders, but not the people that made the patches, or documented the system, or helped manage the community, responded to the pull request politely. The best and most useful open source though has the best documentation, has the best architecture of participation.

Linux kernel maintenance is not a paragon of inclusion and welcoming behaviour. But this post by Linus Torvalds was on point.

So at one level I absolutely _hate_ trivial patches: they take time and
effort to merge, and individually the patch itself is often not really
obviously “worth it”. But at the same time, I think the trivial patches
are among the most important ones – exactly because they are the “entry”
patches for every new developer.
I just try really hard to find somebody else to worry about them 😉

(It’s not a thankful job, btw, exactly because it _looks_ so trivial. It’s
easy to point to 99 patches that are absolutely obvious, and complain
about the fact that they haven’t been merged. But they take time to merge
exactly because of that one patch that _did_ look obvious, but wasn’t.
And actually, it’s usually not 99:1, it’s usually more like 10:1 or
something).

So please don’t stop. Yes, those trivial patches _are_ a bother. Damn,
they are _horrible_. But at the same time, the devil is in the detail, and
they are needed in the long run. Both the patches themselves, and the
people that grew up on them.

Jessie Frazelle argues that closing a patch request that doesn’t get merger is an essential skill for a maintainers and offers some best practices in how to do so. We all need to get better at this stuff.

One reason Egbhal’s research is so welcome is that I certainly underestimated the maintainer issue. As I saw the tweets roll in from what was obviously a great conference – Open Source & Feelings – in 2015 I totally didn’t get it. I had a total empathy failure. I was an asshole. For example, people from the Django community were saying they felt undervalued because they weren’t being paid. My immediate reaction was – get better at building an economic model that works then. Lots of commercial companies rely on on Django ergo you can get paid. Do some business development. Make a commercial foundation.

And yet- I have friends that are Django maintainers. Not my best moment, as I say. Django Girls is an amazing community. It deserves support.

Maintainers come in all shapes and sizes – with a huge variety of motivations and needs. Why should they have to do things in a particular way that suits a particular kind of person or even business model? As Russell points out maintainers are often introverts – and bus dev and hustling may not come easy. And let’s not fool ourselves that everyone finds it easy to get funding – women and black people are at a huge disadvantage by the numbers.

If want to create sustainable and maintainable code we need sustainable and maintainable communities and we need to show a lot more empathy. OSFeels is *awesome*. We need to support the people doing the work. I have a plan in that regard, of which more later.

In the meantime you might enjoy this video in which I try and sum up of these issues in 3 minutes.