This is my theory: we have missed a critical element of how FOSS got adopted in the industry in the first place. That blind spot explains a lot of the problems we have had with getting compensation to FOSS authors, which has created a whole other set of problems for us to deal with.
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.
An OSS project that a previous company heavily relied upon, pleaded that they needed funding or would seize maintenance. As the project manager at the time, I told the R&D manager to start funding this OSS project. In return, we'd get maintenance and features that we otherwise would handle in-house. Roughly a 10kUSD/y handout from a Fortune 500.
"How much do we pay today?", asked the R&D manager, "Nothing", I said, "its open source". "Then we will continue to pay nothing".
So many companies take OSS projects for granted and as a once OSS core developer, I have seen many sides of this. Don't expect anyone to pay you for the work you are doing, and if you find your self not having the capacity to continue, try to see if there's any other maintainer ready to continue it for you, if not, even if it hurts, just leave it alone...
While this plays out with OSS quite a bit, it's not limited to just free software.
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.
This is the game, and people who don't like it still play it, which makes it worse.
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.
Well, yes. But clearly, the 3rd party project is not the core business but would be if there was no alternative. The company would just develop it them self, if deemed necessary. The idea is that the knowledge would be retained within the company instead. The term "its free real estate" comes to mind.
This request for money was both too late (after you've been using the OSS project) and too early (before there was a concrete need). The latter is especially bad because if you haven't had a need yet, why do you think that there will be one in the future?
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.
Interesting - so, to reinterpret: are you saying that one of the significant changes that open source brought about has been to remove purchasing approval barriers for software usage?
...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.
It is _really_ annoying to write the same code repeatedly because the last time was inside some other company, especially when there's no plausible IP involved.
The funny thing is, every eCommerce site already knows this at least implicitly. We've all heard the "every X ms of additional latency on the site reduces our conversion rate Y bps". Adding friction to anything means it's much less likely to get done.
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.
I don't think Jetbrains would be where they are today if not for personal license that grants the right no use the software on as many machines as I like. When it was introduced it cost just slightly more than 3 technical books, and I knew a couple of people who used that math to convince others to switch to Jetbrains.
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.
As a mid-level manager, I'd just whip out my personal credit card and expense it. In 20 years, nobody blinked. Ditto with taking a tax deduction from the IRS for my personal consulting work, which depends on FOSS.
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)
Was that something you learned from someone else, or something you did because you didn't agree with how others had done 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.
I'm not sure you want to use the music industry as the pattern from which to take inspiration for rewarding FOSS programmers. Most musicians don't make more than a couple bucks per month, if they make anything at all. Aspiring musicians waiting tables is a stereotype for a reason.
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 don't make more than a couple bucks per month
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.
The SBOM provides only a small amount of data and would not be sufficient to determine how to distribute payments. Knowing a company uses both PostgreSQL and leftpad would not be sufficient to determine how much each piece of software "deserves" out of the big pot of money. There are also many other problems that SBOMs would not solve:
- 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.
I have had offers to be paid to work on specific things for github.com/pion/webrtc and github.com/pion/dtls. I took one and it wasn't as great as I thought it would be.
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.
There was a pretty good discussion yesterday on this in the comments of a related article. I'll repost below my comment which summarizes the two articles I wrote, but I recommend checking out that thread, as it covers a lot of supporting and dissenting directions.
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).
> (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.
Whenever this topic pops up we get the same few points made again, but progress seems to never be any nearer than before.
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.
Professional developers need to be paid. A big question is, how do you go about doing it?
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.
Can't they just be employees? Would any of the FAANGs notice if they started paying a team of 100 mid-level developers? Add a few admin staff to yearly work out who gets to be in the team of 100, or whatever
Big companies like Facebook and Google already employ a ton of people whose full time job is OSS work. At Google, the number is definitely larger than 100. And this isn't just mid-level people. There are principal engineers doing this stuff.
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.
Setting up a company is a practical way to offer services, especially if you are working outside the US. There is an overhead, at least in my case (living in Europe), like paying for an accountant, but its well worth it.
Some people can. It's not clear that all the people necessary to maintain the current open source ecosystem can. Of course, it's not clear they can make a living by donations either, true! Either way we're talking about something that changes the way resources are currently allocated to shift resources from those with budgets to those maintaining open source.
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."
The usual answer is that customers should pay for "support" that they will not use (effectively a form of insurance), leaving the maintainer free to continue maintaining.
In practice I suspect we'll see a lot more license changes and hostage source in the future.
Getting people to pay for support they won't use sounds to me closer to a voluntary regular donation than it does the "long tradition of setting up a business, having invoices, and providing services for the pay."
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.
Continued maintenance of the software is also included under "support". As are custom feature requests, and sometimes marketing/sponsorship (i.e. the company that pays for "support" can request to be mentioned on the website and in the project documentation). All in all, it works quite well.
After a quick read, my take on this. This basically says we need commercial software that companies pay for. It's just that people are so used to open source and developers have been banging on about how open source is good that no one really wants to admit that open source isn't all that good, we have the 1% of projects that everyone points to Linux Kernel, Kubernetes, etc but the reality is most open source libraries and applications are under-maintained. There are lots of battle tested well used production ready libraries that are being used by thousands of companies that have open issues and open pull requests and no one has even responded to. The whole "you can fix it yourself" is great until you realise that often means "you can fork it and fix it and maintain your own version"
Yeah - but having worked in many companies over the decades, ALL software is this way and most commercial software is even worse.
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.
Then you're very lucky! I'd also question if you were thinking/discussing just the primary product, or also including various edge parts (like the library someone wrote years ago to deal with cleaning up old log data or whatever).
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.
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.
> 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.
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.
> Often this results in them becoming non-open-source, for example, Elasticsearch.
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.
We should all embrace proprietary software? The approach Elasticsearch and other SaaS providers take is anti-freedom and inherently harmful to the "right to fork", which is precisely what makes open source more long-term sustainable and resilient than any garden-variety proprietary package.
Linux still has volunteers working on it, for 5.16 volunteers beat RedHat both by lines changed and changeset counts. Probably some of the (Unknown) people are also volunteers.
Keep in mind that a lot of Red Hat employees use their personal email addresses when committing to the kernel. It has always been allowed (though not necessarily encouraged), and many developers were involved in those communities before (or plan to be after) working at Red Hat, so they use their own email for continuity sake.
Especially if contributing to the kernel is something they only do infrequently rather than as part of their day job.
I believe that the LWN folks take that sort of situation into account, they don't just use the email address domain as an indicator of employer. And of course RedHat people probably do some Linux kernel work outside of paid time if they have pet issues unrelated to their RedHat directed time.
The best maintainer is one who need personally to have a certain software maintained, that's why FLOSS tend to have a mean better quality and less refinements than commercial software.
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"...
I think we need a valuation of the software. If you can show its real value to a business it's much easier to get a business to add a line item to pay for it. Defining the risk to a business of the software being abandoned is another good way to make a case for funding.
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 revenue
The issue is quantifying these things. Companies that provide commercial support provide (usually) some kind of SLA. If software may have a vague risk of a future issue or may be abandoned, that’s pretty hard to weigh if it is worth $x dollars unless everyone is already doing it and it’s ‘industry best practice’, which we aren’t close to yet.
> Pay them real money. In the order of what they could make as senior engineers.
What 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.
A single customer doesn't have to pay the entire cost. Twenty customers paying $10K/year provides a full-time income for the maintainer without the inequality of one customer paying for all the others.
> To keep this short and to the point, we will pay you [in credits] 25% of whatever we make whenever a user deploys your open-source project on Railway. No limits, no minimum amount required, nothing!
That's an awesome idea! Hopefully they'll move to real money soon.
I don't think digital public goods are economically that different from physical public goods.
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".
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.
I'd be interesting if I could, today, look at my dependency tree and decide to donate a number X that would be shared amongst all the dependencies that have declared a donation API (perhaps a cryptocurrency address). This way I contribute to all of what I depend upon, making my own part of the ecosystem healthier.
* 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"
Send them a mail offering funding, asking their preferred payment method and then send them money every month until they stop maintaining the software.
What about a centralized database (i.e blockchain) of all maintainers who get rewarded recurrent revenue in digital money (i.e. crypto) for their projects?
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.
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.