Preact: Shattering the Perception that Open Source Must be Free

I interviewed Preact author Jason Miller about money in open source, maintainer burnout, and growing a democratic community.

Q. Shouldn’t open source be free (as in beer)?

A. We’re all vulnerable to the trap of thinking open source is “free”. That’s never been true. There’s always a cost, but as a maintainer you only really get that once you’re pretty far in.

You think, “Whatever, I’ll just pay for the stickers myself.” But as a project grows, small things add up.

I’ve begun to reconsider the way I think about open source, and ask: is it OK to operate in the open source space, but not necessarily demand all the work be done pro bono?

There are lots of companies with open source products that charge for a paid version, or for support — but projects that aren’t backed by companies have been told, “No, no, you’re not a company so you can’t charge for anything.”

Until recently, you had to either create an LLC, or you had to pay for everything yourself. We have another option now.

Our Open Collective operates like a semi-autonomous company, but without the bureaucracy, which is important because many open source projects won’t survive that overhead. I want this model to grow. I want to shatter the perception, the lingering assumption, that open source must be free.

Q. Who should be funding open source?

A. If you are building your business on top of something, you should help ensure it stays alive and growing, especially if you’re using it to make money. Preact is in the same situation as a lot of open source projects: there are companies whose products depend on it, which means they have an interest in helping it survive and grow.

One of our sponsors refers to their financial contribution as “framework insurance”.

A perfect example is Mocha. Everybody uses Mocha! It’s the de facto test framework for JavaScript. But they don’t have enough maintenance resources. Nobody blames them — Mocha has an unbelievable disparity of users to contributors. Now they’re getting some funding, which can help, and their sponsors will be able to show how their contribution plays a role.

Tangible support for open source is a great message for any company trying to attract developer talent.

Giving money to projects is the same logic as giving developer time. It’s about being a good steward in the open source community, fostering collaboration, and increasing longevity of the projects you depend on. It’s the killer way for companies to say, “We contribute, and you can trace the fact that this project has maintainers back to us”.

Open Collective brings financial support out into the open.

It’s a more transparent version of something already happening on a smaller scale, where open source maintainers get contracted to do things for companies. Right now that’s opaque, happening behind closed doors, and it’s directed at an individual person instead of the whole community. If someone is maintainer number two, and an expert, they should have the same options available to them as the project’s initiator.

Q. How did Preact grow from just you into a community?

A. Preact has a kind of odd genesis story. I didn’t really intend to build it. I was just experimenting to satisfy my own curiosity, down a rabbit hole trying to understand how React and Mithril worked. I was playing with patterns and mashing up libraries.

It ended up working out pretty well, so I shaped it down to what I thought the API should look like. I was actually reluctant to publish it at first. As a serial library author, I got this tingle on the back of my neck, like…

“Oh my god, what are you doing? You’re making another library you’re going to have to maintain!”

It had to be a community-driven project. But in many ways, the code is the least important part of that, which was a tough realization. Four years ago I would have thought that sounded totally silly — I was the quintessential architect guy sitting in a back room.

I’m trying to get better at things that aren’t coding. I’m focusing a lot more on how to teach people and foster understanding. I created Preact to be small, and stay small, because I wanted it to be accessible.

When it first launched, I immediately got made fun of because it was just one big file, which is legit, so I split it up and did another release. But what we lost is being able to pull up that one file in a text editor and understand everything about how it works, in just an evening read (it’s still just 600–800 lines of code if you remove the comments).

This simplicity attracted the initial outside contributions. The more people who could understand the whole thing, the better. Even now, I’m looking at moving some modules from the core to their own projects to simplify further.

Preact is about as far down as you can go toward democratizing a framework: it’s a library that has created a democratic community around itself.

The awesome benefit to this approach is that someone who isn’t me can easily create an add-on or plug-in with no authorization or pull request. They can build anything they want and publish it on their own terms, without having to get it merged into the core.

Q. Why did you decide to seek funding for the project?

A. I don’t have much spare time. I have my day job (which is by no means just during the day), and I also have my open source work on top of that. I found it hard to find a couple hours for anything else, because I was always thinking I could use that time to write benchmarks or whatever.

I was spending a lot of time on stuff that I knew people would appreciate but never really see, like optimizations and documentation. This unseen work is a lot of effort, but you’re sort of alone in driving it — and these are also the very tasks it’s hard to get external contributions on.

I experienced my first open source maintainer burnout last year.

I thought if I were able to raise a little bit of funding, I could either expense my own hours (addressing the tradeoff between a taking a consulting gig and spending time on Preact), or I could attract additional external contribution.

I initially looked at setting up a Patreon page like Evan You has for Vue.js. He was in a similar position, as one guy trying to build a community and realizing it’s basically a full time job. Patreon’s background as a fundraising platform for artists translates in Evan’s case, because people are funding Evan You (his work as an individual).

Evan is such an active leader of that community, and it’s great that this approach is working for him. But I like my day job. I don’t want to quit and become “Preact Inc”. And if down the road I want to focus on something else, and other people have become the key maintainers, I want the community’s resources to transition smoothly.

It’s about raising money as a collective, not an individual. It’s not centered around me.

If you’re fundraising for a community, there’s a clear implication that it’s for the betterment of the project as a whole. By putting the project at center stage, as opposed to a person, there’s no need to explain that. In our case, I think it’s why people were so willing to contribute.

Q. What surprised you when you started crowdfunding?

A. I actually stumbled into the funding launch announcement with barely any forethought: no blog post, no supporting materials, no link from the website, and no explanation of why money would help Preact as a project. If I were going to do it again, I’d prepare all these things to gain more momentum early on.

Our marketing amounted to basically a few tweets, so I was very surprised when so many people were immediately willing to contribute financially. There are lots of people out there who don’t contribute code, but are using Preact and battle-testing it. Previously, if they didn’t experience any problems, I didn’t know they existed.

I didn’t realize how large the Preact community actually was.

Think about the metrics an open source project usually has available: Google Analytics include a lot of documentation reading and drive-bys; Github stars are almost meaningless; and NPM download count is proportional to the number of software releases, so will be weirdly low if you’re a relatively stable project.

Different people are engaging since we started offering a way to contribute financially. They step up and give $5/month because they want to support community-building and outreach, without having to individually evangelize.

How many people commit to donating is a much more reliable metric of users and likely users.

My advice would be to put channels in place for all the different kinds of support an open source project needs, and offer people clear options: write features, raise issues, make a pull request, do code reviews, give money.

Don’t try to hide the fact that the project needs funding, and don’t skirt around that fact that it’s specifically about money, or it will come off as disingenuous. If there’s something users want from the project that money can enable, give them an avenue to make it happen.

Q. What has the impact been? What are the benefits?

A. In other projects I’ve been involved in, there’s normally a super-user group or technical steering committee, which puts the users one level out. But this is different.

Financial contribution gives people shared ownership, and for a project our size we have that to an uncommon degree. People can come in, make meaningful changes, and actually feel like they’ve had a say.

It’s like everyone who uses Preact is on the board of directors.

For example, Paul Lewis has opened a pull request to implement support for progressive rendering, so you’ll be able to throw an immense amount of data at Preact and your CPU will causally go through and render as it gets cycles available. It solves a complex use case in a really elegant way.

That pull request is a directional change that will influence Preact’s journey over the next year, and it came from a user of the library. One person can have as much or as little affect on the direction as they want, without barriers.

Community crowdfunding backs up democratization with something real.

It’s one thing to tell everyone they can have an impact on a project, but it’s another to offer them the same access and outcomes for their contributions that you have yourself. You can expense your time on the project, which everyone can see transparently, and other people have equal ability to do the same thing.

Robert Knight wrote the entire dev tools integration for Preact, making it work out of the box with React dev tools. He’s a genius. When he finished that up, I pinged him and said, “Hey, why don’t you expense some time?” He ended up using the funds to buy a Moto G phone for testing (which emulates a common slow user experience). It was a way to say thank you for pushing the project forward.

Expensing funds transparently keeps us sharply focused on what’s most beneficial to the project.

If developers are donating, I want to give back to them as directly as possible by working on the developer experience. Saving 30 seconds on every build when I run 300 builds a day? I’d pay $5 a month for that!

I’d like to see our level of funding keep increasing. If we had twice the funding, we could afford someone a day a week. Allocating a hard number of regular hours is an important threshold. We’d love to offer something like Webpack is doing with Office Hours (where sponsors at certain levels get access to VIP support and training). This would offer real benefits to people.

Q. How might open source funding evolve in the future?

A. Developers gain knowledge and expedience from open source, but the real beneficiary is the company who doesn’t have to pay its developers to build things. Businesses are built on top of libraries that have had thousands of hours of work poured into them, but which would never have grown organically inside a company.

The employer and the project really have the symbiotic relationship. I would like to see more companies contribute funding so developers don’t have to feel guilty. The default perception should be: of course employers contribute money.

I hope we look back and say, “Wow, it’s so weird that you didn’t used to be able to financially support an open source project.”

My vision is one where developers continue to take informed technical positions and support best of breed tools by using them. And at the same time, their employer actively identifies the projects their company depends on and makes sure to back them financially.

It’s not actually that far out of reach. We have the model. Some companies are already doing it by contributing to the Open Source Collective, and directly to the projects they use.

We need to democratize all sides of open source.

I might be good at writing code and terrible at writing docs (totally hypothetical!). But that doesn’t mean there’s not a huge need for docs, and if donating money enables a great writer to come on board, that’s fundamental. Open source collaboration can become a market for all contribution types: time, code, expertise… and money.

Want to be a supporter? Donate to Preact now.