Supporting the randos
Let’s talk about some things that we as open source creators need to get better at, including supporting other developers ourselves.
(A talk I delivered at at the first CodeDAO meet-up during Berlin Blockchain Week in August 2019, about sustainable open source development).
Introduction
Hi. I’m Ricardo Méndez, Technical Director for Europe at Samsung NEXT, where we are doing venture investments in software innovation.
Some of these investments go into companies that build open source, like SignalWire, but I’m not here to talk about NEXT’s portfolio companies.
What I want to go into is my own experience as a rando working on open source and how that shaped my perspective on open source sustainability.
Heresy!
I suspect I’m going to be the local heretic.
I fully agree with one of the event’s premises, which is that open source software development is poorly incentivized.
But frankly, the nominal centralization is nowhere near the top of my concerns. I care a lot more about how to address the sustainability issue.
I intrigued by the idea of dit, which we are going to hear more about later. I’m very curious to see where it leads. But I’m going to come right out and say that I don’t believe what we need are more tools.
I get it. I’m a technologist. I like building stuff. Building stuff feels easy, or at least enjoyable, while getting people to pay for stuff is a chore.
So let’s dive right in.
Initial thoughts
Who here is familiar with Mastodon?
Who uses it?
A few years ago I wrote a short bit on Mastodon about how we were going back to the days when servers were run by random community individuals.
When I wrote it, I was thinking specifically of online services - the rise of things like Mastodon and Pixelfed as a counterpoint to the Twitters and Instagrams of the world.
It came about because I was explaining to a friend how Mastodon worked, how it was a network of sites run by random people and operating on very simple terms of service (which could vary from site to site).
I closed it by saying:
The plummeting server/software costs help, but it would be impossible without volunteer labor.
It behooves us to support the randos.
That is not only true of Mastodon, of course. It is true of the internet as a whole.
The internet runs on randos.
Um… randos?
Now, what do I mean by “randos”?
A “rando” is a random person. Someone who just “showed up”, or just “happens to be there” but you have no idea where they came from, or maybe why they are doing what they are doing.
Now, we aren’t randos, are we?
We all have different circumstances, and interests, and focuses on things, and more importantly, very specific reasons why we pursue and maintain the projects we do.
Maybe it’s because we thought a tool needed to exist. Maybe it’s an ideological inclination. Maybe it is just out of intellectual curiosity, to explore a space.
The part that we tend to forget about, though, is that the further removed someone is from what we are working on, the more likely we are to be perceived as a “rando”.
The less of a direct connection they have with what we create and maintain, the more likely we are to be abstracted away as a fundamental reason that a library or application continues to exist.
It’s hard to get support when people see you as a rando.
So how do we go about this?
My own experience
I’ve been on both sides of the table on this.
Numergent
I’ve maintained and contributed to multiple projects over the years.
The ones that I maintained the longest were somewhat niche - libraries for autonomous agents and coherent noise generation. If you don’t know what either of those things are, don’t worry about it - you probaly don’t need to.
They were fairly popular. Combined they have about 1200 Github stars and 300-odd forks. I haven’t really updated them in a few years, but the one I maintained for the longest was about 6 years.
I got zero direct funding for these myself. Developed them on my own time, while running my business, and never charged a single cent for a license.
I usually went with the MIT license, mostly to remove friction from myself. I wanted to make it easy for people to adopt them, while not having to field too many licensing questions.
We’ll come back to friction later.
While I was happy to do this myself, and it is something that led to projects for my business, it’s not something I can recommend to anyone as a sustainable or scaleable approach.
Stack Zero
On the other side of the table, I just headed the Stack Zero Grant at Samsung NEXT. We announced it November of last year, requesting submissions of non-commercial open source and research projects working on decentralization. Earlier this year we disbursed almost $500k among nine different grantees.
Not saying this to pat our own back. I want to dissect this case as a sustainability.
Suppose I have that same half a million dollars as a steady stream, year after year, from a magical never-ending money fountain.
Even on that very idealized scenario, you have a lot of questions to answer. For starters, what do we do with the money?
Do we fund the same projects? Or do we pick new ones?
Do we fund them on the same amounts? Or do we give more money to fewer projects?
While we are sorting out these questions, the projects themselves don’t know if they are going to get funding from us again.
Grants aren’t scalable. Grants aren’t sustainable.
And more importantly, if you actually care about progress in the industry like I do, we have to acknowledge that “long-term disruption won’t come out of grants”.
(I can’t take credit for that one. Gonçalo Pestana said it over dinner a couple nights ago. I intend to flog the hell out of it, though)
Poverty level
And in case anyone doubts that this is an endemic problem, I recommend you read André Staltz’s thoroughly documented Open Source below the poverty line.
He surveys 58 projects, calculating how much they get from donations across Patreon and Open Collective, and how much the project would be able to pay each full-time contributor per year.
Of those projects he surveys, he finds that 53% are below the poverty line (defined as about $12K per year for an individual) and a further 31% are below industry averages.
That’s a full 84% of projects surveyed where they couldn’t pay industry averages - never mind rockstar salaries - to their full-time contributors.
Some cases are flat out terrible.
Is anyone a Java developer? Or know what joda-time is?
Joda-time is a widely used Java library to manage date/time conversions in a sane fashion (Staltz reports 77,378 dependencies). I’ve used it myself in the past in multiple projects. It gets exactly $0.
Yes, a few very visible projects are doing well. But it’s not just an issue of project popularity - he also highlights some massive imbalances.
Core-js, which has 2,431,975 dependencies, receives about $16k.
Babel, which has only 350,015 dependencies and in turn depends on core-js, receives $350k.
This is a prime example of what I mentioned earlier: core-js is a dependency that is abstracted as just one of Babel’s moving parts. Since Babel is more visible, it gets more attention.
Its creators are not randos.
Notice also that being a project that’s in green doesn’t necessarily mean you’re doing brilliantly, or that you will be able to continue supporting yourself in the future, but at least means that you were within industry standards for this specific year.
Clearly there is room for improvement here.
But before we expect the software industry at large to get better at supporting open source, I think there are a few things that we need to get better at ourselves.
We need to get better…
Get better at figuring out why
And the first is getting better at figuring out why would someone give you money in the first place.
Remember those two projects I mentioned that I didn’t charge for?
Funny thing about those projects is that they generated a lot of business. I hadn’t meant that to be the case, though, which is partially why I picked the MIT license.
MIT license is a way to just give without expecting anything in return. The only thing the MIT license asks of its users is that they hold themselves accountable for any issues emerging from having chosen the software, instead of coming around to blame the creator if their house catches on fire or something.
My whole thing was removing friction, and MIT was the cleanest, most frictionless license that I felt comfortable using.
I wanted people to use them. On those libraries, the code was clearly modularized, fairly well documented, and on top of that I also put out a project with examples on how the components played together (which doubled as my own test environment).
So this had all the ingredients for anyone to take them and build upon them, without ever reaching out. I’m sure a ton of people did.
Still, agencies and game studios reached out, asking me to build things for them.
Why then did those large companies come to me for help, instead of taking the code and using it themselves directly?
Luis Villa from Tidelift gave a talk in 2018 at Monkigras about friction and sustainability in open source. There was a key point from the talk that stuck with me: we want to make our software frictionless, because it being frictionless means easier adoption; however being frictionless also means that there is no need for anyone who is using the software to reach out to you.
One example of friction he cites is licensing. MIT license is frictionless, but GPL is not - it introduces friction if anybody wants to build on your project but keep the source closed.
I didn’t get it until after listening to Luis’ talk, a good two years after I was no longer actively building those libraries. I realized that there was a hidden source of friction that I got lucky and stumbled upon: choosing the right component to use was easy enough, putting them together was trivial, but getting the exact desired behavior was not.
Getting a particular behavior was more difficult because said behavior emerged from the interaction of multiple variables and parameters. Acquiring an intuitive feeling for these required familiarity with at the very least the concepts involved.
Someone at a studio who found the library could play with it, demonstrate that it worked, but when it came to getting the right behavior, on a deadline, it was easier to pay me than to keep experimenting.
This was a source of friction which benefitted me.
I suspect that if we want to support ourselves as open source developers, that is one area in which we need to get better at: figuring out where to reduce friction and where to leave just enough that people still have a reason to pay you.
So figure out which aspect of the software is naturally frictionless for you but provides friction for others, because friction is one reason why people stop and think about the people behind the software they are using.
Get better at reaching out
Now, suppose the ideal scenario. People know who you are and strongly associate you with what you build.
Well, even if you are a household name in the space, you can’t take your funding for granted.
A great example is Zooko Wilcox, one of the driving forces behind Zcash, a privacy-focused cryptocurrency.
His company, the Electric Coin Company, is VC-funded. Funding, however, has a way of running out, so part of Zcash’s funding plan was to dedicate 20% of the issuance to the development team during the first four years of Zcash’s existence.
This funding decision took place in 2016, before Zcash launched. The original 4-year window ends on October 2020, so Wilcox is already active explaining to the community why they should care about on-going funding.
Notice that Zooko is a household name and pretty much a super star in those circles, but he’s still not above reaching out to the community to get their input, and credit others who are also involved in the project.
“I can’t make this decision for the community. When we initially set up the Zcash project years ago, I set the shape of it in consultation with many others, including Nathan Wilcox, Andrew Miller, Matthew Green, Naval Ravikant, and many, many other people that I consulted.
I set the shape of it, but the Zcash community breathed life into it.”
As Zooko describes it:
“I decided that the Founder’s Reward would be 20% of the first four years of issuance. That was 20% of nothing.”
He goes on to state that it is the community itself that gives value to Zcash, so without their approval and continued use, any issuance is worthless.
You should read the whole piece. This sort of humble, detailed outreach, executed more than a year in advance before the team needs it, is a great example to follow.
As you read it, you’ll notice that Zooko is not only making a rational argument. He speaks to the community personally, he tells them why Zcash is important.
He not only goes into how the team has consistently done good work, brings out third-party comments as validation, and points out how the company needs to continue supporting the great people working on the platform, but he also describes it as a positive alternative for society.
See what he’s doing?
He is making it matter on an emotional level.
Get better at making it matter
Because a key tool to stop being randos is making an emotional connection.
Making your project feel like it matters to users will depend on making an emotional case.
And sadly, this means that you need to get good at selling it.
I know.
I know the impression we tend to have of the word “sales”.
There is a certain oiliness to the idea of selling. I use it as a negative regularly. If you hear me say something is “too sales-y”, I don’t think you’d expect that to be any good.
But those skills have a value, and if you want to support yourself building open source software, you may need to acquire them.
It’s almost as if expect that if people just understand the rationale of why something is necessary, they will help fund it.
I would argue that emotional appeal is just as important.
For instance, I’m sure everyone understood the importance of OpenSSL way before April 2014 - that’s why we used it. But the project still wasn’t properly funded until people felt the emotional impact of Heartbleed and started wondering if their systems were actually secure.
So whether you are selling your boss on letting you open source your contributions, selling the community on funding you, or selling companies on why they should adopt your open source code and pay you for it, to me there is only one conclusion.
You need to sell someone, because to get funding, you need to stop being perceived as a rando.
A personal question…
One last thing, before I close…
- Who here has ever donated their own money to an open source project?
- Who has done it this year?
- Who does it in a predictable, regular manner, say, by a Patreon where the money gets charged monthly?
If we want others to help support us even though we are randos to them, then we need to get better at supporting other randos ourselves.
Published: 2019-08-30
