How to Pay Professional Maintainers
words.filippo.io
words.filippo.io
In the middle of the S curve for adoption, software development teams were struggling with the fact that someone in finance laughed at the idea of spending money to make money. R&D is a cost center, and anything that reduced costs would make life better for the company. Well, any costs except labor, which are some magic other shade of money that can't tell that you just spent 1000 man hours on something that should have taken 300 but you first had to squeeze another application onto aging hardware that was slower than what some of the developers have at home.
In some cases these people were power tripping. They seemed to enjoy being able to say 'no' to any requests, able to use their purchasing veto power to make you do what they want you to do. Everyone had one of these stories. Many had one about the current employer.
Then along came Open Source. When you said, "I want to use X" and this person said, "We're not paying for that, no," you could cheerily shoot back, "Oh but that's the best part, it's free, so you don't have to pay for it. Have a nice day!" and tralala your way back to your desk while they are left trying to think of a way to force you to do things their way. That is why it's used everywhere. Because nobody could stop us.
So we've democratized the power dynamic quite a bit (you still have general managers forcing teams to use Oracle because otherwise they have to explain why they have been sending that much money to Oracle if half the applications are running on Postgres, so they pull the dick move of banning Postgres), but that money problem is still there, as it always has been. If I can't buy copies of TeamCity, which is commercial software with a commercial license, I sure as hell can't get the company to send $100 with no contract to some internet randos just because I say they're saving us a million dollars a year.
You can't educate your way into fixing that problem. People have been trying literally for decades. There's a plumbing problem here, and until that gets fixed you can plead with people all you want to fund OSS, but it's not going to happen.
...and that we're stuck in a local minima where we now have to get over other, similar approval barriers to send money back towards open source projects? (in the case of projects that accept funding, at least)
(it's possible I've misinterpreted; and, for what it's worth, I think there are other reasons that FOSS has succeeded in addition to what you say - but I like that way of looking at the current landscape)
I observed a number of people say one thing in a group setting but would confess to other things off the record. The purse string issue was high for a lot of people, but as you say that wasn't the only motivation.
I think too that we oversold the Enlightened Self Interest value to the company in open sourcing internal tools. People worked hard on code that they didn't want to have to write again somewhere else, especially not several times. My current and future job satisfaction are elevated by convincing my bosses to free the code, the Greater Good is also improved by doing so. Nothing makes me want to leave like feeling trapped, and any work I do that has value past my expiration date is a big part of feeling like being here still is a choice.
But I think only a few companies ever enjoyed the fruits of that effort to the degree that we were all telling them they would. Sun Microsystems in particular. But the industry benefited enormously, so history will probably be fairly kind.
Even for commercial software, if it were easy to purchase, I'd still have to figure out how to make sure we comply with the licensing, get the key into the server, figure out how to deploy it (and not be able to inspect the software to see how it works if I need to).
Or I can just go to github, make sure it has an acceptable license, and run import-from-pypy foobar==1.0.
That license is worded specifically for me to use my private copy at work without exposing my employer to liability.
It's surprising to me that more organizations haven't followed suit. But many of these tools run either on the server or on a CI/CD machine so I'm not sure how you'd work that.
"Not as much as we'll pay replacing it"
Boss knew we were using our integration box for customer demos. I don't know how many times I explained that the entire team would be blocked by 1 pm on demo day, and some people would be blocked as early as 10 am, for want of a cheap box. I had to make a chart that showed man hours lost versus the cost of the new machine. Six weeks. The new server would pay for itself in six weeks. He said something sheepish about how he thought I meant a '"server" server', not a workstation class machine. Still don't know what he was thinking. A "server" server still would have paid for itself in six months, and he would have the luxury of me not bitching at him every time he forgot why almost everything that didn't get done on a Thursday slipped to Monday afternoon and asked me again about slippage.
You are almost always spending more on an early adopter than they are paying you for your software, but typically that's with the understanding that you are re-selling those solutions to new customers.
That hasn't always been the case. I've worked at a couple of startups where one of our customers was exuberant about how critical we were to their roadmap, but part of why they were so happy was because they were getting a sweetheart deal, and we couldn't figure out how to tell them no, or sign them to a more lucrative contract because the one they have is already so nice, they'd be fools to sign a different one.
And then they go pikachu face when we either went under or got sold to someone whose career (and probably no small part of their job satisfaction) was built around saying No if you were lucky, and Fuck you, Pay me if you weren't.
It might have worked better to treat the OSS project as a "free trial but we pay start paying after 90 days" from the beginning.
IMHO the issue is that users are lazy and have truly-zero risk tolerance, and that in turn means that FOSS developers need a lot more money per donor, which in turn means fewer donors.
I'd like to see a single consolidated donation per unit time, that's then divvied up __based on your usage__ i.e. homebrew/apy/yum nags you from time to time and makes it one-click to make a decent-sized donation to the 100+ projects you actually use.
(obviously, there's disagreement about what "use" means, but the UI would make it easy for the donor to make adjustments...)
(and yes, I'm volunteering to work on something like this and/or help fund it)
I haven't run into a story like this often. Not in my own history, or talking to others over beers. I think you might not realize how unusual your reaction is, in the grand scheme of things. If you could try to convince some of your peers to do the same, a lot of people you never meet will benefit greatly by it.
What the PRS does is collect royalties when the works of their members (music) is broadcast on TV or radio, performed in public (even via a shop tannoy system), stream or downloaded.
Companies wishing to use the music must sign an agreement with the PRS to give them an annual fee, and the PRS distributes it as fairly as can be based on some sparse data (i.e. sampled radio play, reported shop mixes, etc). Most played artists get the most, but everyone gets a little.
What if the IT industry did similar?
We have SBOM ( https://www.linuxfoundation.org/blog/what-is-an-sbom/ ) as a standard amongst companies averse to making software licensing mistakes, and just to have a record of what software at what version is running within an infrastructure.
It should be more trivial for this industry to have a collection agency that fairly allocates payments to the software and dependencies actually in use... than it is for the PRS to do what they're doing.
Yes the PRS has legacy, but all legacy starts somewhere. If you're running code I've written and still maintain, SBOM will tell you so... and a collection agency can come up with some payment structure (free to organisations below this much revenue, not-free to organisations above so much revenue, etc).
Don't invent something new. Steal the idea and structure from those who made it work.
Also how would you even start to decide how much postgres gets vs colors.js? One is a huge project with highly specialized code, the other inserts terminal coloring characters into a string.
Most musicians aren't represented in the sampled plays of radio. Those that are, are getting paid nicely.
We don't have to rely on that, given that most risk averse large customers are already asking for SBOM manifests showing all software licence information, version numbers, etc. We have better data available to us.
- How to handle forks? Would forks of a project be counted as their own project or as new projects entitled to funding of their own?
- How to handle projects with many contributors? Would (say) antirez get all the money for Redis or would everyone who has ever submitted anything be entitled to a share? Both options seem ripe for abuse and this doesn't even go into the relative difficulty of (say) README changes and handwritten assembly patches for BLAS code.
- Imagine a big open source project like React. It is obviously "owned" by Facebook and it stands to reason they would get a large portion of any monies allotted to React. Would a large portion of small companies paying royalties to Facebook be a desired outcome of this system? You can repeat this with MySQL/Oracle and golang/Google as just a couple of simple examples where you would have small companies paying taxes to big companies just to use the open source software.
- Could the owner of an open source repo sell their rights to someone/something else? If so, how could you prevent a company systematically buying up all the rights to open source and charging a tax to all other companies that want to use "their" software?
There are just so many holes in the idea of forcing people to pay for open source that I can't see this getting anywhere. The lack of payment for FOSS has been the biggest driver for adoption over paid software, if you take that advantage away it just becomes paid software without maintenance guarantees.
When we engaged OpnSense, they had a website, had an email for support/service inquiry, and even a website to "buy support subscriptions"...
This made the process VERY easy to get through our legal hurdles, and "buy 20 hours/year in support" (which we likely won't use even half of)... we also contracted a professional service to simply sit down with a developer to go over how they intend the image to be created/automated... while we could figure this out, it was another opportunity we could classify as a professional service to get through our systems. This is certainly not "paying them what they are worth", by any means, but our budget allowed us to spend a few thousand a year at least.
Apache, on the other hand, has been difficult... We want to support a specific project, and would like a similar relationship, but the developers are not listed anywhere, and there's no support mechanism except through 3rd parties. It seems your best bet is to put out a request, and see if they are an active member of the project, and try to negotiate with them individually? That's not going to be an easy sell to management.
We need both sides to shift for this kind of transactions to become commonplace.
I really value the autonomy/independence I have now. I enjoy not having to make compromises. No deadlines to meet, no business goals and no creating stories for promotion. Instead I make the software as good as I can.
Working a job unrelated to your Open Source project is the best place to be. You will probably make more money. You don't have to worry about clients paying on time. You don't have to worry about things like health insurance or 401k.
Open Source is also great for the resume. Since it is all public you have a body of work that makes it much easier to get another job.
→ https://news.ycombinator.com/item?id=30741702
Open Source volunteerism is the result of the early hacking culture and of what makes the Internet special: people choose to experiment and share their work, and their work can reach every corner of the world. It has no significant parallel in other industries, it's beautiful, and I owe it my career.
However, it's not a sustainable, fair, or effective foundation for an industry with the responsibility to power modern society. We need the critical role of Open Source maintainer to professionalize. This is most likely to happen through capture by large intermediaries, but I wish to see it happen through the formation of a serious professional role, organized independently or in small firms, like lawyers.
This will require changes both from the maintainers [1] (become legible, get a LLC, send real invoices, offer guarantees) and from companies [2] (pay the maintainers, pay them real money, pay for maintenance, and keep paying them).
I'm sure every business will be completely on-board except for the "pay" part (and possibly the "real money" part as well.)
Companies are allergic to anything that involves paying money, especially to developers outside the company, especially for "free" open source software, which is believed to be maintained and supported gratis in perpetuity by the "open source community."
As someone noted above, it is possible that someone who wanted to use open source software once encouraged management to believe this lie, thus turning it into a permanent and non-negotiable requirement for all open source software, forever.
To their credit, this has enabled an enormous transfer of value from a skilled volunteer workforce to tech companies.
In the end, the "dream" of being paid for your open source work seems to be very similar to having a small SAAS-like business but without having to do marketing, customer acquisition or any of that boring "business stuff" that comes with running a normal company. No leetcoding required! You just write code and somehow people will show up and pay you. It's a perfect fantasy for the HN audience, which is why articles about it come up so often.
Donations don't work. Even recurring ones. Large companies have legal hurdles in paying that way. The legal hurdles are very large and are legal ones. Things they don't control.
A long tradition has existing among some of setting up a business, having invoices, and providing services for the pay (e.g., some consulting, logo on the site (marketing), etc).
Setting up a business and handling this this way is how other industries have long worked. I think of my local electrician. It's not hard.
Just an idea of how to turn an idea into a practical reality.
But, anyway, since anyone can use open source for free, what are open source maintainers going to be invoicing and getting paid for? It seems to me it's not going to be maintaining the software itself -- since you can use the maintained software without paying, anything you pay for maintenance is effectively just a voluntary donation, not a straightforward invoice for work.
So whatever you're invoicing for and getting people to pay is... something other than maintaining the open source software. It seems to me that is not solving the problem of "how do you get maintainers paid", in fact it's taking the people who are well-placed to be maintainers and reallocating their time somewhere else to something they can get paid for, and hoping there's enough net profit they can keep maintaining in their unbilled hours just because they feel like it.
The OP's perspective is more: "How do we get maintainers paid for maintaining? If you are a company with budget who wants to, here's how. If you instead pay someone for doing something other than maintaining, which is often what people end up doing (paying for features or what have you)... that does not actually make maintaining pay, it doesn't work to make maintaining pay."
In practice I suspect we'll see a lot more license changes and hostage source in the future.
I guess it's a way of making a voluntary regular donation seem like a traditional invoice to satisfy the bookkeepers, but that's not what I thought @mfer was getting at. And if it magically worked to produce what are effectively donations, we probably wouldn't be having this conversation. "
But yes, you are talking about something other than open source as the more likely future route, which is why i asked @mfer if they were! That's the straightforward way to get people to pay for software -- make it not open source, so they have to pay to use it.
This does aggravate some of the OSS community, however. Calls of "Google is taking over C++" or "Embrace, Extend, Extinguish" are common from the community. This represents a big problem: the community does not agree about what future they want to build.
1. There are business that maintain open source software, today. That are paid maintenance. This can work for some cases. This can even work for libraries as some already do this.
2. Linux is a good example. There are legal organizations that surround it. From Linus to most of the contributors. People are paid for the work. Through legal organizations. With contracts involved. It's not an example of open source with volunteers doing the work out of the goodness of their heart.
3. Open source software can be great. But, just like an electrician doesn't just do electrical work in order to make a living... the same applies to open source software development.
4. There is a lot of open source maintained by companies that is not their core business value. This is reliable and production ready software. Sometimes people do make change requests to fix or improve these.
This is true, but in my experience they end up complaining about the same thing. Competitors using their code to make money. Often this results in them becoming non-open-source, for example, Elasticsearch. I personally think the approach that Elastic has taken is the right approach and is what we should embrace instead of the whole open source is great and we should all do open source to help our careers.
> 4. There is a lot of open source maintained by companies that is not their core business value. This is reliable and production ready software. Sometimes people do make change requests to fix or improve these.
These are also often under-maintained.
> 3. Open source software can be great. But, just like an electrician doesn't just do electrical work in order to make a living... the same applies to open source software development.
I highly suspect the majority of them only do electrical work to make a living.
It's important to note that Elastic was a VC funded company that is now a listed public company trying to make open source maintainership their businesses as a high growth business. This is different from being a sustained maintainer making OK to decent compensation for their work.
The type of business matters. Is it high growth (or VC which is high growth) or is it consistent maintaining.
> These are also often under-maintained.
Sometimes they are and sometimes they are not. Are there any stats on this?
> I highly suspect the majority of them only do electrical work to make a living.
My point is that they don't ONLY DO electrical work. They have legal businesses, they do invoices, they handle accounting and money comes and goes, etc. They don't get to forget how businesses and finances happen while hoping for donations.
Especially if contributing to the kernel is something they only do infrequently rather than as part of their day job.
The difference is, you can’t fork and fix it yourself when it’s closed source from someone else. and a surprising amount of code running in every company it’s ‘someone else’s’ code even when it’s internal and part of the same company.
Even at the FAANGs I've worked at, it was pretty common for bugs to never get triaged or even looked at for long periods of time that impacted some users, or serious bugs that weren't in the critical path for common use cases to stay unfixed for years. Libraries that weren't actively 'owned' by anyone sometimes go even worse.
Honestly my personal opinion is "when labeled 'professional' or 'enterprise' is something similar to Star Trek Enterprise ship, something that keep having terrible troubles, extremely bad design (for instance a single 'reactor') etc"...
After that I think it's worth having a new corporate funding method. I think there should be a "co-op patreon", where the software funding requirement is presented, and companies join the patreon group and equally share the cost of supporting it, adjusted by revenue amount. In this way both a mom-and-pop and a FAANG can contribute fairly to the project. The more organizations that join, the less they have to pay, as once the funding cap is reached, no more money is needed, and the cost is spread across more and more orgs. If every company that used curl joined such a group, they'd all be paying pennies.
So, next steps would be:
1. Standard process to evaluate software value
2. Standard provess to evaluate software risk
3. Stock letter to use in companies to propose funding
4. "Patreon" clone that enables corporate co-funding adjusted by revenueWhat advantage is that to the company over just hiring them and having them continue to work on the open source project. From the company’s perspective, not only does that cover paying for maintenance, it also gives them far more control over the direction of the open source project by directly employing the main contributors.
That's an awesome idea! Hopefully they'll move to real money soon.
Expecting private companies to fund the (micro)infrastructure that enables their business has never been a solution. It's a libertarian pipe-dream, leading to a spaghetti of "toll roads" and service outages.
The obvious, time-proven solution is to fund this infrastructure through an accountable, transparent, public institution. There should be a central source of truth where you can check if X project is being publicly funded, at least within a particular jurisdiction. Grants would be simple: $X over Y years for "maintenance and general development", then reevaluate after Y years.
If the federal government won't do it (although they already literally do this for government software projects...), then at least a forward-looking state could get things started. "libfoobar is officially a Texas Digital Public Good..."
But leaving this up to the good-will of private, profit-seeking companies will simply never work in the long-run. Cost-cutters will inevitably come and ruin it, with no recourse for the maintainers. They will be the first to be "laid off".
- Organisations give money that goes into Jhipster organisation coffers
- Committee / treasurer manages this chest of money
- Bugs are found and assigned bounties depending on how severe they are
- PRs are made for those bugs, when accepted and merged the money is released
I'm glad Filippo is de-stigmatizing high-tier sponsorships:
> Designing, building, managing, and growing an Open Source project demonstrates all the skills required of a Senior Software Engineer. That means maintainers can access $150k–300k++/year compensation packages.[1]
> ...
> $1,000/month without benefits is a nice way to show appreciation, but won't achieve any other goals.
Smaller sponsorships do still contribute towards an overall paycheck, but aren't sufficient alone. While the majority of my sponsors are at $25/mo. (I should kindly mention that Filippo is one of them! For which I am very grateful.), I have tiers for $250, $1000, $6000, and $11000 per month as well [1]. I only have one or two total sponsors among the higher tiers. Currently, the majority of my expenses are covered by a single executive sponsor (ZeroSSL). The rest of my expenses are covered by independent professionals or small companies (which I also rely on -- thank you!) Without both the higher-tier and lower-tier sponsors, I would not be able to sustain a living working on Caddy.
(By the way, sponsorships drop out on a regular basis, so it's always important to sign on new sponsors regularly.)
So when I say to large companies: "You need an enterprise sponsorship to support your business use of Caddy," I mean it! It would take hundreds of $25/mo. sponsors to cover living expenses and match a senior engineer's salary, or it would only take a few enterprise sponsorships -- and it's way more affordable to sponsor along with a few other large companies than it is to bring the expert in-house exclusively. Ideally, we'd achieve a healthy mix of lower-tier and higher-tier sponsorships.
Maintaining a large and complex project like an extensible, general-purpose web server is a lot of work and requires expertise I've spent almost a decade tediously accumulating. I don't want to have to find other work right now, and with hundreds of thousands of dollars of their revenue per hour relying on a web server that a student designed and developed after-hours in his senior year of college and spent years mastering since then, large companies depending on the project shouldn't want me to leave it either!
After I got married last month, our open source sponsorships are suddenly supporting a family of five. Yet another reason -- albeit a more personal one -- that I strive to reach sufficient sponsorships: now I have something I care more about more than software.
I really love working on Caddy every day. I hope it continues as companies continue to sponsor its development.
* Specifically mention that you're after someone with nontrivial open source experience/maintenance experience and you'll accept it in place of Leetcode
* Some inkling that you've thought about titles/HR considers "maintainer" as experience
* Provide the expected time commitments from interviews upfront. Likewise for compensation.
* Expect part-time or contract work. If full-time, explicitly allocate time to their OSS.
* Remote, if part-time or contracting
* Async friendly. I've had 1 "real-time" meeting in OSS (total).
* Post a spec/contact details in a reply to this comment, or "Who is Hiring"
In all seriousness, the author and his project Filippo are on the right track to help bring income to humans maintaining open source software. Another team doing a similar stellar job in the crypto sector is GitCoin and their grants to software devs.