It isn't so much that companies are unfairly using others' work. It's that if you're going to use an open source tool in your business's codebase, you'll inevitably need support, upgrades, and bug-fixes, which translates into you putting pressure on the maintainers to do more work. By all means, use those people's previous work to put something amazing out into the world quickly. However, when you inevitably need help, be prepared to either: 1) Have people on staff ready and capable of contributing to the project in non-trivial ways; 2) be willing to either hire or pay the maintainer(s) market value for their time, just like with actual employees.
This was so easy to "sneak" into the process where I work:
> The fastest way to get results is for me to contribute a fix.
> Can't we copy their code and fix it locally?
> Absolutely, but then we won't get any fixes from them in the future, unless we set up our own build infrastructure and have a team make sure that they merge across changes regularly.
... which starts sounding like lots of money. Your employer cares about the bottom line, so make it about the bottom line. The Linux Kernel is a fantastic example of egoistic altruism in action. You don't need to hire people to fix arbitrary things in OSS (although that would be appreciated), just fix the things you care about.
Finally, getting a PR merged into a big project makes any other method of training look grossly incompetent - and it's free. Go ahead and cancel that company-wide Pluralsight or Linked-in Learning contract, now we're saving money.
Don't ask for open source developers, ask to fix things in open source.
That doesn't solve the problem completely, though, as truly fixing it requires review time with the existing team. It's still unpaid labor, but now it involves code review and collaboration.
I think we still need people paying open source contributors.
Agreed. It does bring the egos to the altruistic water, other arguments become much easier once they have experience with the value of OSS participation.
Furthermore, if a company has a culture of fixing things in open source, people are exposed to it. I can guarantee that many great potential personal time contributors have never been shown the door.
They perfectly demonstrate the disadvantages of private forks. They don't get security fixes, other bugfixes, or new features that userspace software will eventually use.
That's complicated and has a lot to do (as I understand it) with NDAs, copyright, and the general air of secrecy surrounding the low level details of proprietary hardware.
> if you're going to use an open source tool in your business's codebase, you'll inevitably need support, upgrades, and bug-fixes
I started using open source software and tools almost exactly 20 years ago in my career as an embedded software engineer. In exactly one case a company I worked for needed support from the developer, and in that case they hired the developer, ESR, to enhance his project, GPSd.
Perhaps it is different in other parts of the software world. From what I hear, the web dev folks like to shake and bake large collections of 3rd party libraries and tools. In my experience however, companies I've worked for have never placed the burden on open source devs to fix issues or add capabilities. They paid employees and contractors to do it, and generally, where appropriate, fed those contributions back to the community.
I do feel companies are not supportive enough of open source software, but I do not feel there is any burden placed on developers of said software other than those that they choose to take on themselves.
I don't think the pressure is always, or even ever from the company to the open source maintainers. Instead it will be from the developers working for the company, who are asked to deliver their feature, and require improvements or new features from open source to help them do it. They will personally cut issues, possibly insist, be rude, and name call the project or maintainers when they can't get traction.
I think this might happen also from University students who are similarly stuck for a school project of some sort.
Mind you, most people don't do that, but it takes only a few bad apples.
Agreed, although I am also mostly an embedded dev. I think the social aspect of GitHub creates most of the pressure and I do not like that it is seen as synonymous with open source.
Nobody stops you from just not adhering to requests. If people get nervous they can fork and do it themselves.
My company uses open source (who doesn't?) and would never think to place anything on open source devs.
Something I never understood is why don't more maintainers just post the rate at which they'd be willing to do the work other people want?
I suspect very few open source maintainers are doing so well financially that there's NO rate they would accept to perform other people's requests for their own project.
Whatever number it would take to motivate you to do the work, just put it out there. Aside from the fact that you might get paid, there's a hidden benefit: cheapskates who don't value your time as much as you do will quit asking for freebies.
Lots of people do this as a hobby - getting paid for a hobby is a very good way to make it not fun anymore. If its consistent $$$ that might be worth it. For a one shot thing, maybe not as much.
I think it also can be difficult to mix volunteer stuff with money. Posting in a bug tracker that multiple people work from which anyone can take on a bug from, that you will do it for $x, can make it feel like you're using a community resource to spam your business. There's probably other places where that type of advertisement is ok, but it ads an extra element of difficulty in doing these sorts of things.
Sure, but for almost everyone, there's a dollar figure at which they're willing to stop having fun and start making money. Maybe that dollar figure is $1,000/hr for some open source maintainer out there (I bet it's much lower for most of them).
Why not put a line in the readme which says, if you want to commission a specific change, send me an email to discuss, my consulting rate starts at $XXX/hr. Or there's a $YYYY project minimum, or whatever is meaningful to the maintainer. If that feels too aggressive then leave the dollar figures out. Hard to imagine this running afoul of any reasonable community norms, especially for a project which already has the problem of too many people asking for things.
Maintainers can handle this problem however they like, but I have a hard time feeling sorry for someone who's not getting paid, if they've never asked to be paid. I think they would be better off asking.
And again, if no one inquires - then nothing changes, it's still a 100% hobby project, with the bonus that the expectation to do other people's shit for free is gone.
Having a full-time and well-paid job means that open source work is in my spare time, and that time is limited and precious. I don't actually want to be paid for that. Or have any written or unwritten major obligations to others. The amount I need would have to be a full-time job that pays better than my current full-time job, and that will be expensive.
I've previously worked on large open-source projects like Debian, taking upon many obligations and essentially working a second full-time but unpaid job. That's definitely unsustainable, and I quit for several reasons with this being the major factor. Working like this is definitely not in anyone's self-interest.
Like another poster in this part of the thread, I have tried my hand at open-source consulting work, and I didn't have a viable business. You can't rely upon the sporadic needs of end users; you need something more sustainable, and not every project can support that.
This is coming from a UK perspective, but if you're earning money in anything more than trivial quantities, you need to register as a sole trader or create a limited company. That brings with it legal obligations, and other obligations, like bookkeeping, separate bank accounts, corporation tax payment, company reports and tax returns, personal tax returns and more. That makes for a lot of friction to take payments, and is a huge amount of hassle and inconvenience. But these are all factors in why I don't currently have any intention to make money from open source projects. There needs to be a way to narrow the gap required to make the transition from unpaid to paid work without all of the overheads of running a full company. Maybe there are ways around that to make it an easier burden to bear.
I have the same issue as you, not in open source but in freelancing. Occasionally I'm approached by someone in my network who needs a few hours of software development. In the past I tried this, figuring that I may as well earn a few bucks on the side during my free time.
But then I realized the enormous overhead that comes with taking payments in Israel. I'd need to open an account with the tax authorities and deal with a bunch of paperwork I don't understand. So now I'm busy learning the tax system or hiring an accountant... it's just not worth it unless they're going to commit to a large amount of hours, but I do value my free time as well. So either you pay me enough to quit my full-time job at a big company or forget about it. It's hard to do small amounts of freelance work because of the onerous regulatory environment.
All this is different for USians, who have to file tax returns every year anyway and simply need to add another source of income on their 1040.
Exactly so. The first year, I thought I would do all the accounts myself... with zero formal accounting knowledge. After all, with just a few invoices and payments, how hard could it be? The answer was... it's an entire discipline I know nothing about, and while theoretically simple, you have zero practical experience or understanding of what the government requires of you, and there are lots of tax rules and accountancy terms you have to properly understand. So you waste days doing it, and worrying if you got anything wrong, because you are legally obligated to do it correctly and file everything on time. That's a lot of worry and time to save some money.
The second year, I just paid an accountant to do it for me. It was very expensive given that the accounts could be written in their entirety on a single sheet of paper. But I had the peace of mind that it was all done correctly by an expert, and they were responsible for ensuring it was all done by the book and filed properly. And they found a few mistakes I made in the previous year.
The accounts are essentially a fixed overhead; it doesn't get much more expensive if you do 10 or 100 times the business. But that makes starting out hard because it's a big annual fixed cost.
I do wish freelancing was easier, be it on closed or open projects. It does seem like governments have stifled entrepreneurship with overly burdensome taxation policies. I'm not opposed to paying income tax, but I do think it could be made sufficiently simple to pay for small freelance activities that it's not deterring it, and that would be beneficial for the economy overall. Many of these small jobs could be the catalyst for the formation of a new company if they take off.
If OSS project maintainer offers “fixes for money”, then could there be a conflict of interest? Merging a PR that scratches some obvious itch would be equivalent to robbing my family of money I could earn by charging a BigCo and doing it myself.
IMO one of the best ways to contribute to OSS while making some living is to do product development and/or consulting work, and structure it so that you can methodically encapsulate and open up the components involved. Of course, this unfortunately does not apply to every project out there, but I believe Django was born and had been developed this way for example, as well as probably many well-known projects that we don’t know the precise origins of.
This can probably be fixed by splitting the platforms/features into tiers. Tier 1 is always fixed ASAP, tier 2 means that good contributions will be merged, tier 3 changes will only happen if sponsored.
Maybe but I've reached out to open source maintainers to offer them contracting work focused on their library and they have pretty much unanimously replied that they are too busy. And we were willing to pay above market rates to work on a product that has a significant global user base. There's definitely culture, process & funding problems around open source but for the most part being an open source maintainer seems like it's very good for your career.
I suspect being an open source project maintainer is a self selecting grind.
I imagine if someone is willing to pay a maintainer $1000/hr (implying they are that desperate to hire someone), the maintainer wouldn't need a line in the readme to hear about it.
As someone who tried their hand at doing paid "consulting" work on an open source project i contributed to (just very briefly when i was between jobs. I wasn't very succesful at it. Nobody offered me $1000/hr) most of the jobs were very small and there was a surprising amount of overhead between getting different jobs (maybe not that surprising, i was probably just naive). Decently big $$$/hr translated to less than i thought it would in practise.
> Maintainers can handle this problem however they like, but I have a hard time feeling sorry for someone who's not getting paid
What exactly are you feeling sorry for, and would $$$ alleviate the issue? People don't go into open source software to become millionaires, and money will not fix burnout.
> with the bonus that the expectation to do other people's shit for free is gone.
People will always try to get you to do shit for free, even if its a paid project by a company. Not being paid at least means you can tell off the people you don't like really easily.
This was exactly my experience of "consulting". I too was between jobs, and it seemed like an idea worth trying. At the very least, something interesting to keep me occupied while unemployed. And it was an interesting experience to set up and run a company, which I don't begrudge. But when I looked at my effective hourly rate, it was below minimum wage.
It did give me some perspective on running companies, negotiating contracts and billing with an hourly/daily rate vs fixed price per contract. I would certainly increase what I was billing by several times were I to repeat it, but having a sustainable source of business before starting would also be something I would factor in.
> Lots of people do this as a hobby - getting paid for a hobby is a very good way to make it not fun anymore.
This is true, but I don’t particularly like having my work thought of as a “hobby.” In the last three years, I’ve worked harder than I ever did, for a paycheck. I also feel as if the result of that work is the finest-quality software I’ve ever written.
My GitHub Activity Graph is solid green (and absolutely not “gamed”)[0]. I code every single day; often a lot of coding. It’s all been unpaid. The work I got paid for, never got into the public domain.
I’m currently working in closed-source, but the main reason is for a marketing embargo that will eventually lift (might be awhile, though. It’s a not-small effort). Nothing particularly proprietary or extreme. Most of my work is fairly pedestrian.
> The overjustification effect occurs when an expected external incentive such as money or prizes decreases a person's intrinsic motivation to perform a task. Overjustification is an explanation for the phenomenon known as motivational "crowding out." The overall effect of offering a reward for a previously unrewarded activity is a shift to extrinsic motivation and the undermining of pre-existing intrinsic motivation. Once rewards are no longer offered, interest in the activity is lost; prior intrinsic motivation does not return, and extrinsic rewards must be continuously offered as motivation to sustain the activity.
I can only speak for my projects that maybe 5-10 people use because they are rather specialized and nothing special. I simply don't want to be hired. I have a job and my projects are for fun.
I am no idealist on these issues and earning your keeps as a open source developer sounds really good. But there is a difference between hobby and job, even if you can bring it close together ideally. But for hobbies I prefer to set any obligations myself.
Of course I could set my rate to a large number, but I think it is important that people understand the motivation behind some projects and that is learning, having fun coding, sharing or something else, depends on the individual I guess. Saying 'no' can still take time...
I go for #1 pretty frequently but my biggest frustration with trying to contribute to open source projects is: the repository whose owner pops in every 6 months or so to merge a PR or two, then disappears. Just enough activity to hope that they might eventually merge my outstanding PRs, not quite dead enough for me to just fork and move on with my life...
Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.
Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now.
Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard. For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintainer.
The expectation that unlimited PRs will be reviewed for free is corrosive and contributes to the core-maintainer burnout described in the article.
>because they only solve the problem that the PR submitter needs solved right now.
This is something that can lead to angry interactions between maintainers and pull request raisers. Never mind adding technical debt, pull requests can outright break uses cases they don't care about in order to implement the single use case they do care about.
raiser: "Merge my PR. It fixes this issue."
maintainer: "It fixes this single issue but you've broken this for everyone else."
Some of this burden can be offloaded to robots though, via static types, unit tests, linting, and automatic code formatting. I even go so far as to envision my unit tests as a squad of soldiers laying in ambush around my use cases, waiting to pounce on transgressors.
This. If your company demands anything from the maintainers, be ready to back your demands with either appropriate compensation for the human or appropriate effort for the software. (Or an appropriate combination of both.)
I understand where you are coming from but I imagine few open source projects were created with the idea that they'd eventually make the big bucks on support contracts.
I think the important point is that if money should be on the table. After that it's a business negotiation as to how much you are willing to pay.
An interesting point is how you can implement a process to make this whole thing not consume non trivial amounts of time. By way of example:
Bob is a developer. He finds bug in his code comes from an underlying open source library. This gives Bob 3 options.
- Bob can either dig into the library and see if he can fix it and maintain a fork.
- Bob can fix it and try to get corporate approval for submitting an upstream patch.
- Bob can try to seek approval and budget to pay the maintainer of the project to take a look at the problem.
If companies I have worked for are anything to go by 3 sounds like a herculean task. 2 sounds possible but involves effort. 1 is a minor annoyance (with high probability of major issues down the line).
My main point was to note how far apart the paradigms are.
I think you're right that few projects are started with aspirations to gaining support contacts. It does seem like it might help OSS be more sustainable though. If I could transition to independently working on some of my projects I'd be glad to make a fair number of compromises to do so.
2 is definitely the best option and can be surprisingly low friction, especially when Bob points out that otherwise there's an ongoing maintenance cost to the business to keep merging the upstream. Bob also has his personal time even though that shouldn't be on the table.
There's a great Strange Loop talk by Evan Czaplicki (of Elm fame) where he alludes to the challenges of maintaining an open source project.[1] In it he describes how feedback often starts as an innocuous "Why don't you just...?" where the person making the request doesn't have the full understanding of the system as a whole and may see their request as a simple one-off that can be done quickly.
To answer them fully, the open source maintainer has to respond with a long explanation of why their suggestion isn't an option. Or, maybe they don't respond and now the original poster doesn't feel the community is supporting them. This asymmetry can lead to poor communication in the community.
I've been working on an app and was reading about the pros and cons of going freemium vs. pay up-front. I was surprised to read that people suggested the pay model is better for indie devs because with free, you'll have more users, but you'll also get worse feedback from the free users. Maybe there's a correlation between seeing something as free and feeling that the work behind it is trivial?
Interestingly, that comment was made by an HN user who laments that Elm was mocking them and is one contributing factor to them leaving Elm, due to having such a dictatorial style where Evan thought he knew better than the community.
> While you're surfing the web, you ought to thank Jacob Thornton for making it so pretty. He's a programmer who, along with web designer Mark Otto, created Bootstrap, free software that the pros use to make their sites look spiffy. If you've ever noticed that a lot of websites have the same big chunky buttons, or the same clean forms, that's likely because an estimated one-fifth of all websites on the planet use Bootstrap.
I don't blame Jacob, but man the WWW would probably be better without Bootstrap. Again, it's not Jacob's fault, he made a product that was so good everyone wanted to use it... so everyone used it. It feels like the Demolition Man future, where Taco Bell is the only survivor of the Franchise Wars.
I very much disagree. Bootstrap is good and makes making websites quickly easy.
The ideas of Bootstrap now live in Tailwind and other CSS frameworks. I haven’t used Bootstrap proper when I switched to Tailwind in new projects though.
Bootstrap is nothing like tailwind. nor their ideals. You look at 2 websites made in tailwind and they look completely different. Look at bootstrap and its the same bloody site.
There are TONS of people out there writing code and opening the source. These people don’t do it for company sponsorship or money or to improve their CV. They do it purely for the pleasure of someone else using it.
It’s just that only a very tiny fraction becomes popular. That’s when the problems start. Some may see their software being adopted by millions and may start feeling envious of those that make money using it.
Maybe unpopular opinion here, but I don’t see why they should get sponsored by a company. They made the software open source for a reason, and others used it based on the terms it was licensed. No foul play here.
On the other hand it’s well within their rights to ask for money to continue supporting it and developing it. Just because they made something open source in the past doesn’t mean they signed up to be forced to support and develop it indefinitely.
I agree with you. If you chose a license you regret, its kind of just your fault. Why would you pick MIT license for example, if you didn't want to allow free commercial use?
If you "make it free" and choose a very relaxed and unencumbered license to encourage adoption of your project and make it more popular. And then you do get popular, and start thinking people should now pay you, it seems like a bit of a lure. There are often alternative open source or closed source solutions. Yours might have reached this popularity not because it is the best, but because it is a good one that is also free and unencumbered.
And now like you said, you're free to change the license for all new code to something else, make it paid, closed, or any other restrictions. And that's fine.
That said, this is about licenses and having companies use your stuff and renumeration and all that.
I think a bigger issue, one that is justified, is the toxic interactions you might need to deal with if your open source project becomes big. People can act really entitled, when you don't owe them nothing. And I find it kind of weird how people will actually act more entitled to something that is offered to them free and open source, than if it was something they'd been paying for. Which kind of baffles me why that is.
> If you chose a license you regret, its kind of just your fault
Agree. The only possible exception I can think of it if you make major contributions to an existing project, and of course use the licence they chose. Even then though, you've voluntarily agreed to those licence terms.
> They do it purely for the pleasure of someone else using it.
Exactly! I've been open sourcing all my projects, often even under MIT or similar, and hope that one day it will be useful to someone!
I even sit down for sometimes hours to write documentation, comment my code, make it maintainable. It gives me a certain joy to make it all neat and tidy, just in case someone ever comes across it (which might or might not ever happen, but if it does, it'll be nice!).
> I even sit down for sometimes hours to write documentation, comment my code, make it maintainable. It gives me a certain joy to make it all neat and tidy, just in case someone ever comes across it (which might or might not ever happen, but if it does, it'll be nice!).
I've been doing that for so long, that it is completely habitual.
My stuff is generally not popular. I'm my own best customer, but I write (and document) everything I do (even the one-offs), as if they will be a corporate legacy.
One of my projects (a fairly massive one, actually) became something a lot bigger. It is now being maintained by a skilled and energetic team. They don't always do things the way that I would have, and that's a good thing. The project is thriving.
The best thing I did for it, was step away, after developing it -alone- for ten years.
One option is of course to get a job in one of those companies that is a user of your project. You get to work on your and possibly other similar projects, and the company gets an employee they already in advance know is going to be skilled and relevant. If your code is very useful for some, it ought to be possible to harness its popularity to offset some of the potential negative side effects.
This is pretty backwards in spirit. If you own the code, there is no reason to let any corporation use you like that. Just change the license to something anti-corporate if you started with too permissive one, it'll make it apply to all the new commits and force such corporations to pay for commercial license or stop using it. If you think they are willing to hire you to work on your project, they are even more willing to just pay for it.
How much better the world would be if open source was fully funded by some of those tech billionaires whose fortunes were made by sitting on its shoulders.
I agree. I would love to see more things like Summer of Code or grants towards open-source software. Is there a sustainable way to fund open-source work apart from corporate benefactors who "own" the software?
I would prefer crowd funding because with corporate sponsorships often come subtle obligations for corporate friendly adaptations and sometimes weird expectations.
While there is some truth to it and describes what you should be careful about, it fundamentally doesn't understand the different motivations behind open source.
Creators know that individual users can also create horrible expectations not restricted to software development, but you aren't suddenly half dependent on a company in which there is probably one guy calling the shots about your project and maybe it is better not to marry him.
That’d be awesome! Should note that a lot of popular software is (at least in part) paid for by the large companies. For example, Google probably has several engineers working on chromium. Facebook has several working on React and React Native. Apple has several working on Swift. Automattic (where I work), has several working on WordPress.
I said essentially the same thing 10 days ago and this is what Walter Bright, creator of D, said: "There are a number of generous corporations and individuals helping us out in various ways, including cash contributions to the D Foundation."
Open source has become yet another way for big tech companies to exploit laborers. If you are an independent developer working on an open source project without a copy-left license, you are a fool.
The language is a bit too extreme in my view. You release OSS knowing that anyone can come and pick it up. Even if they make a dime off your sweat. Pick your license, fine, but there's no reason for the devs to get upset about it because there's no lack of information out there.
That being said, companies should kick down some love to the OSS projects they use. Especially big companies for which it's just a charitable write-off anyway.
At every company I've worked I've lobbied for us to make donations to open source projects we depend on. Every single time it quietly dies in legal. There must be a better way.
I mentioned this elsewhere on this thread. I completely agree with the sentiment.
In a "when I'm king" kind of way I thought it would be great if tech leads had a modest budget for open source contributions (with a minimal amount of oversight to assure it wasn't being funneled off to their friends account).
It might also help with legal / finance to have these funds earmarked so that they only had to approve it in the beginning.
OSS could use similar licensing as some SaaS where it's free for personal use or commercial use up to certain limits and then you have to pay. This would ensure developers can use it freely but at some time a company would have to either pay it or ditch it.
However I see two issues with this model:
- the community will shit on it like it's not real OSS
- big companies will start banning the use of such licenses
The other alternatives many are doing are paid support, priority issues for sponsors, paid for issues, etc.
I am not from legal, but too me there the problem would be: you use a product, but you dont 'buy' it, you 'donate' to the guy who made it, who is also 'super nice' and fixes some stuff about the product you need. This looks like a work/service/purchase agreement in disguise. Actually you dont want that to be possible.
From what I gathered the problem is often that most corporate legal departments are overworked so small donations to open source projects are just never high priority enough to displace other tasks they have in their queue.
I tried commercial FOSS development. An older version was available at no cost, the newest version cost money. Both were MIT licensed.
If you were a company, and wanted to pay me, it was easy - send me a PO and you would get the source code to the newer, faster, more capable version.
Nothing in that looks like a donation.
I did it this way precisely because giving someone money for being "super nice" and distributing no-cost FOSS software DOES NOT FIT with the accounting mechanisms of most companies.
Even with this, I was at one pro-FOSS workshop. One of the presenters described how they used my no-cost version and how great it was. (Did I know they used the software? Not until that day.) I pointed out that many FOSS projects are underfunded. Their response was that it was so hard to get their company to fund FOSS projects (along lines that cageface observed).
I pointed out that it's really easy to pay for my project.
They still never bought a copy or support contract.
I came out of that workshop convinced that the primary reason companies like FOSS is because it's generally available at no cost. Not because it reduces long-term dependencies on external parties, not because it improves software development methodologies, and not because it's an essential liberty. But simply because of the cost.
> "I came out of that workshop convinced that the primary reason companies like FOSS is because it's generally available at no cost. Not because it reduces long-term dependencies on external parties, not because it improves software development methodologies, and not because it's an essential liberty. But simply because of the cost."
This was, or at least should have been, known from the beginning; I've certainly been saying it since the '90s. When people were proclaiming FOSS to be "free as in beer and free as in speech", it was pretty clear that most people stopped listening after the first four words.
Yes, most FOSS business models of the 1990s were based on secondary effects. Like "people will pay you to add features / support the software / integrate your software in their system."
I deliberately did NOT use that model. Rather, you pay $$$ and get commercial software, which happens to be under a FOSS license.
In other words, I wanted to see what happens if it's not "free as in beer". If you are willing to pay for software, will you pay more, or less, for a FOSS license instead of a commercial one?
Turns out, people don't care - they want the cheapest one. At least, my customers' willingness to pay more for a FOSS license doesn't match my economic risk for selling under a FOSS license.
That cost is measured in dollars and in friction, not just dollars. There’s no software that I won’t pay $25 for if it helps my work. There’s some software that I’ll pay $100 for. It’s again difficult in the $100.01 to $1000 range and opens up again over that (only if the value is there of course).
It’s fair to assume that slightly different purchasing approvals are needed in the buckets above. In all cases, I’m making an RoI calculation and a return-on-effort calculation.
$0 and not AGPL hits a sweet spot on both RoI and RoE.
The software was in the $25K+ range. It's a rather different market, and different sales techniques -- made harder because my FOSS-only distribution model meant I couldn't distribute an evaluation version with more restrictive licensing.
The non-FOSS pricing is cheaper, but still in the $10K range. My last sale took about 15 months from start to finish.
FWIW, I got strong feedback that people wouldn't buy it with GPL licensing. It's library software designed to be embedded wherever you need it, so I can understand that.
One of my customers' ERP system is a nightmare so they outsource many purchases to a reseller. I didn't understand what was going on when the reseller contacted me, and ended up being added as a supplier to my customer's ERP.
I then got paid twice. After 9 months and multiple inquiries I still don't know how to give them their money back!
That actually happens more than you might think. I've worked at a couple of open source product companies in the data management field. In both cases we had deals from corporate users who wanted to ensure we would continue to maintain software they liked. The sums are not small either--I've seen them run into hundreds of thousands USD.
It definitely helps keep the lights on--and also helps justify the open source model to investors and the like. (Anyone reading this who has done such a deal, y'all rock.)
My open source projects have given me the opportunity to collaborate with highly motivated and smart people. They've made me well-known in my niche and have brought me great job opportunities. They depend on relatively stable APIs and don't require a lot of maintenance. Writing open source code has been a positive experience for me, even though it doesn't directly make me any money.
it sounds cynical, but before starting any code, I now ask myself "will a corporation profit from this labor?" and if so, I work on something else instead. I never have a shortage of ideas, so it's not a big deal.
Not him, but I'm currently working on an unauthorized port of an old Japanese computer game to the Sega Saturn. I imagine this has no commercial value.
It was a reaction against proprietary closed source software that restricted your rights as a user. To avoid this unilateral license control GPL and it's derivatives were created, but so many open source maintainers refused to use it instead using licenses that were essentially unilateral in the other direction.
And so frankly they're the architects of this, not "big evil corp".
Even with a copy-left license. Take for example Linux. It undergirds the entire Cloud technology, and social media, as well as Android. There is no way the contributors have seen anything but a minuscule portion of the value generated.
Would love if governments could better appreciate the value of open source and free software. Some sort of granting process that could determine which projects are worth funding on a sustainable basis would be wonderful. It's a great opportunity for access to technical expertise, avoiding vendor lock in, lowering costs and international collaboration if done right.
Done poorly, it's throwing good money down a drain - but I would think the ROI would at least be as good as scientific grants (for which it is usually hard to get any type of sustainable infrastructure funding).
It's important to set boundaries early on. I'm working on this analytics library [0] and this game server management app [1] at the moment.
I started the first one with my own website in mind and as it gained some popularity, decided to try to make a commercial product out of it. Instead of making everything open-source, I develop the platform closed-source and keep the core (this library) open-source, but set limits to what can be contributed and under what conditions. This isn't clearly communicated in the repo yet, but it helps to stay sane.
For the game server project, which is older, I see a lot of feature requests and small contributions, because people actually depend on it. But boy, the support requests drive my crazy sometimes. Even if you only have a hand full of users, they can get demanding some days, when a new DLC for the game is released for example. I really want to support it and keep it up-to-date, but I sometimes have to ignore them. This week someone asked me if I could support them setting it up as they had trouble making it work for their drivers. Turns out they're a professional e-sports team. As soon as I asked for compensation, they didn't write back (after sending them 4-5 emails, taking half an hour to write). This is when it gets frustrating...
I don't know how to fix the issue, but we, as open-source maintainers, should value our time.
> “I couldn't grab dinner with someone after work,” he says, because he felt like he'd be letting users down: I shouldn't be out enjoying myself. I should be working on Bootstrap!
That's an attitude problem on the part of the developer. He shouldn't feel guilty for providing insufficient free support.
It's easy for you to say "he shouldn't feel that way." But it's a different thing to be in the position yourself of having hundreds of thousands of people depending solely on you to fix a problem (even to just review and merge). The pressure is real, and there aren't a lot of healthy outlets to relieve that pressure.
I think the only thing you can do is to be up front about setting expectations very clearly and prominently in the project.
If it is a large project relied upon by a lot of people or businesses, that's when you start charging for support when the issue is mission critical, or you encourage others to do so and provide a link to their support business.
The demand for free skilled labor is huge, and always greater than the supply.
> But it's a different thing to be in the position yourself of having hundreds of thousands of people depending solely on you to fix a problem (even to just review and merge).
They chose to depend solely on me. They, and not I, are responsible for their decisions.
For anyone interested in this topic Nadia Eghbal previously wrote a book called 'Roads and Bridges' that is freely available on the internet. It's well worth a read:
I'm curious about when open source coders transition from enjoying sharing their product to feeling obligated to support their product to wanting some form of monetization when supporting their product becomes a job. Is it normally companies causing this or unrealistic expectations?
I know myself, when I put something in open source I feel a responsibility to maintain it for no reasonable reason.
It usually happens after a series of poor life choices lead the developer down a path of financial destitution. They spend their personal time curating PRs to fix typos or expand their CI matrix to support N x M combinations of runtimes and cpu archs. Then one day they lose their day job, realize they have no savings, and that none of their FOSS contributions will help pay their rent.
Is it actually feasible to just say "no contributions or support requests will be accepted for this project"?
Or to have an hourly rate for support requests right up front? ("if you want me to fix this project for your use-case then I will charge you $100/hour to do that")
And in the case of abusers, can you add a list of specific indivuals to the licence that are specifically disallowed from using the code in any form for any purpose? e.g. ("anyone is allowed to use this project for any purpose, except the people listed in the shit_list.txt file, who are not allowed to use any of this code for any purpose at any time").
As someone who works on open source, sure, you can totally do that–but for me, personally, those aren't really things I would want to do. The first locks out people who want to contribute, which kind of removes half the reason you'd open source something in the first place, the second feels like you could leave in bugs and ransom them for support money, and in the third you are introducing your own subjectivity in ways which frequently do not go as planned. I totally understand why people would do all three, but for me personally they just aren't for me, and I hope you can understand why some people would be turned off by such projects.
I guess I'm happy to open-source my code for other people to use, but I'm not at all interested in acquiring an unpaid job as "maintainer" (and I really don't care how many other people use my code).
You can always choose to just say those things, but if it's worth doing, the language and approach should make it more likely that the general community response will be better for you than saying nothing at all. To me that means being gentle and professional about wording and boundaries, (which is easier provided one is not absolutely shattered by their work experience). Examples:
- We are currently backlogged and may be unable to accept contributions or support requests.
- Need support? We may be able to help. Contact us for bespoke personal or commercial support and development rates. (Packages start at...)
- We are evaluating license revocations for those who violate our clearly-written and frequently reviewed community standards, which you can review at this link.
Support abuse situations are often best dealt with situation-by-situation, though, and unfortunately I didn't see a specific, real-world example in the article. Sometimes just the possibility of someone taking advantage is a turn-off for a good project owner, so I would add that at the very least it's a good idea to have a general communication plan & principles in place before that happens.
I'm curious why there is a need for "professional" standards here?
I feel that this is, by definition, not "professional" - that would require payment.
Also, the imbalance of jerks behaving like jerks but everyone else has to act responsibly: in a work setting, sure - you don't get to choose your colleagues and you need to get along. But in this setting - why can't a maintainer just tell a jerk to fk off?
I think that's an important ground rule, for sure: You don't _have_ to do any of that.
You can absolutely tell a jerk to do whatever comes to mind. If you want. I know I've done that before. (I would add that I regretted it because, in part, it complicated community discussions later)
In a lot of ways, I think that once you feel like you _have_ to do this or that, especially the professional stuff, your personal values (i.e. "but I don't wanna... This is supposed to be fun, that's what I want more of in my life") will start pushing back on you and you'll have an internal conflict on your hands.
However:
- I think it's a better idea to identify specific people with whom you can really have fun and let go. "General public" has never been a good return on heavily-subjective communication investments. But with a little calibration? Figuring out who else is going to make this fun and enjoyable? That's where the fun can really pick up. I have fond memories of traveling to different spots in the world, and meeting close FOSS project friends.
- There are tons of different degrees of professional standards. You can be humorous, you can give funny examples. Or you can just try to meet a reasonably objective "not a terrible communicator" standard.
- It's also about what you're _not_ perceived as: Rude, out for money, vindictive.
- Unfortunately the word "professional" really echoes our social values as a group. But that's just the lay of the land right now. Some of the best communication training Joe Average will ever receive is only available in a "professional" setting. The word and system suck in a lot of ways, but there's some good stuff in there if you can set aside the parts that annoy you.
Anyway, don't do this professional stuff, it will make your life more tedious and boring, etc. ;-) But those little points of leverage have helped me and that's where I'm coming from.
I can’t read the article. I’m very interested, but Wired has become such a cesspool of popovers, pop ups, advertising, tracking, and general dark patterns that I just can’t go there... even with an ad blocker the experience is annoying and sucky.
The cure for insufficient ad blocking is more ad blocking.
! row for wired
##.itemlist .athing:has(.sitestr:contains(wired.com))
! the following comments/etc links
##.itemlist .athing:has(.sitestr:contains(wired.com)) + tr
! the following spacer
##.itemlist .athing:has(.sitestr:contains(wired.com)) + tr + tr.spacer
If companies start putting together tiger teams to support open source then they never really get to everything they use, just what open source projects are most important to them.
When companies fork/adopt/insert themselves we have concerns over corporate influencing, sustainability, and independence.
When companies just throw willy nilly money at big hunking shells like the CNCF it gates projects into this very corporatized world that is quite distinct from open source culture, and again damages open source.
This just touches on the contribution model, this doesn't even touch on the thousands if not hundreds of thousands of license violations (if you're behind on updates who has time to go enforce licenses?) It mentions but doesn't touch on corporatization or undue influence.
I'm not sure I know what to do but it's a problem worth solving.
> When companies just throw willy nilly money at big hunking shells like the CNCF it gates projects into this very corporatized world that is quite distinct from open source culture, and again damages open source.
How does giving money to something like the CNCF gate projects? How is the world those are developed in differ culturally from open source culture?
I've developed for CNCF projects and random projects (some of which have become popular). I didn't notice a culture difference. I did notice an outside support difference.
The CNCF is pretty distinct from organizations like Debian or The Linux Foundation, and even Debian comes under the same sort of fire I'm about to lay down here. At this time, I think it's more skepticism than the understanding of what the problem is, but it boils down to corporate influence and what level of influence companies are allowed to have on projects.
Companies have several methods of influence:
- Financial contributions (and the projects nature of dependence)
- Developer interest and representation (eg: when a mega-corp installs a developer and combines that with things like funding)
- Board representation
A quick anecdotal example was the whole kerfuffle about Google using it's influence to insert kustomize into kubectl. [0]
Big organizations like Debian or the CNCF are attractively large targets for the above concerns.
Nadia's book, Working in Public: The Making and Maintenance of Open Source Software, which is mentioned in the article, inspired me to become a GitHub sponsor. Nothing big, just $10 per month to one of my favorite open source developers. If you can afford it, I recommend others' do the same.
I predict that the problem of overburdened open source maintainers will be solved by adjusting expectations, rather than new funding or new business models.
Open Source maintainers owe nothing to non-paying users. The norm should be that only those that pay get support.
Requiring payment for support would mean that poor people who switch to open source are going to have a bad time. A better option would be to create a community of users and contributors that are willing to support each other and improve the project at the same time. The new GitHub discussions feature can help facilitate creating such a community for those projects that use GitHub.
How do you differentiate leechers from contributors?
"Github discussions" looks to me like Github discovering user forums. It's not an innovation — user forums have been around for decades.
The expectation that maintainers will provide unlimited support to poor people illustrates exactly why maintainers burn out. Maintainers don't owe poor people anything, any more than they owe corporations anything.
The "leechers" are part of the ecosystem of the project too, putting down people who haven't yet started to contribute is a sure way to sour your project in their minds and prevent them from ever trying to answer other folks support questions, let alone contribute code to the project. So don't try to divide the community like that, instead treat everyone as future contributors and create spaces for them to start contributing in their preferred way, one step at a time.
What has become clear over time is that most users don't contribute meaningfully to open source projects. The burden falls almost entirely on core maintainers. From the article:
> But, with the exception of some big projects—like Linux—the labor involved isn't particularly communal. Most are like Bootstrap, where the majority of the work landed on a tiny team of people.
Offering unlimited free support is guaranteeing that either the project will fail when the core maintainers burn out, or that the core maintainers will live in perpetual misery.
Don't offer unlimited free support, create a space where users can and do help out answering support questions and turning them into well-researched actionable bug reports, which can be turned into well-written pull requests, which turn into knowledgable and ongoing codebase contributors. Its (one of) the marketing funnel but for open source contribution.
Community development is a lot of work. I was very active in the Apache Incubator for several years, so I've seen many projects build exactly what you're talking about.
Once the community exists, it doesn't get easier. Core maintainers now have more to do: reviewing contributions, steering architectural discussions, teeing up starter issues, nurturing prospects, resolving personality conflicts...
It's not impossible to do that kind of work as a hobbyist, but it's more sustainable when there is somebody getting a steady salary to do it. But not everybody enjoys such tasks, and not every open source project needs to be able to be economically viable.
All of this leads to the kind of burnout described in the article. And what makes it worse is the guilt tripping that if they don't either respond to every support request (reasonable or unreasonable) or build a community that does, they are not living up to their supposed obligations as open source authors.
This is really evident even in small projects. Many (most?) open source developers have full time day jobs often in software development. Adding the responsibilities of not only the software but also project management and customer service can be a huge burden. I think it's the combination that leads to a lot of dead projects. Then of course you have the other end of things with projects like Docker or Ansible that have large teams and often corporate funding but just can't keep up with the sheer firehose of issues and PRs.
Last I checked with Tidelift, they target primarily web OSS that's truly ubiquitous – think vue.js, Angular, Python requests and similar. Their $$$ reward is based on installation numbers across Tidelift's subscriber base, not value added or cost saved.
Definitely not a model that would help most (read: more niche) open source developers.
For example, I maintain a Python library with 10k+ Github stars and millions of monthly downloads, and was told by Tidelift it's not even on their radar. Zero reward in Tidelift's reward system.
Which is not to say they're not helpful to others, they might be. Just to manage your expectations vs their marketing.
What about automatically "crowdfunding" open source projects? Idea: would it be possible to design a system where we distribute a membership fee to open source projects used?
Let's say NPM would cost $10 / month per end-user. This would be redistributed to all the packages you use. (Or, similarly, cumulative membership fees will be distributed according to # of projects that re-use your package).
Have there been experiments like this? Any thoughts?
That idea needs a bit more baking IMO. It seems obvious to me that the immediate consequence of this would be that we'd be rewarding trivial but widely used packages like left-pad[0], and thereby incentivizing the creation of a hundred clones of every trivial feature.
I think that would have a negative effect on individuals and open source developers. Have a dependency on npm, 10$/m. Have a dependency on Nuget, 10$/m.. I'm at 20$/m for my project which may or may not be a commercial product.
With this model, the fees could increase with each distribution platform your project depends on.
Rather than developing UBI, we should be working on figuring out how to solve this issue.
Maybe ask ourselves how best to pay people for the work they have already done on Open Source.
That would be a better way to create a future in which people do what they love and are good at. That would reward the right things. That would make people feel good about the social justice angle.
As someone who grew up in India, contributing to OSS has always been the best way for junior developers to get noticed by recruiters.
Due to the sheer number of applicants, recruiters are only interested in the ones that are truly passionate about coding - exemplified by OSS involvement or side projects.
I'm not saying that it is right, but it does give the much needed exposure to junior talents in order to foster their growth.
I’ll be honest: I do appreciate devs who love programming so much they sometimes do it for free. I still pay them (inc interns), but everyone I’ve known who was great at programming did some amount of it for free somewhere along the way (because they can and they like it), whether it was open source, programming contests, or just checking out some new tech on their own and never shipping the code anywhere.
Even though every line you’ll ever write for me will be paid, the fact that you did something worthwhile for free is a positive signal to me. You don’t have to show that specific signal to be hired, but if you do, I’m not going to ignore it.
If you see that something did some programming for free, is it because they love programming? Or they love the increased chances of getting a job/money?
What do you think the ratio is? The recent Hacktoberfest/ pull-request/ T-shirt fiasco (see https://news.ycombinator.com/item?id=24658052 among many) shows that signal is definitely gameable.
You might be worrying that I can't tell the difference between a gamed/BS pull request and a genuine side project.
If someone "games the system" well enough that they can cogently explain something interesting about their side project, do I really need to know if they grudgingly learned it because of money concerns or out of a love of solving puzzles with computers? By the time you can explain your side work and have some level of understanding/explanation that you can share, that's strongly positively correlated to me.
If you happen to be bad at programming and grudgingly trudged through it, that might show up once you're employed, in which case it was a false-positive. But it's at least a somewhat expensive false-positive for you to generate.
Sure. I suppose that if you go deep enough, my signal is "will write good code here", which is suggested by "can write good code", which is suggested by "has written good code" and "wishes to write good code", which is suggested by..."did a side project" or "doesn't only write code when someone is standing there to pay them for it" or <whatever else>
Everything in an interview process is an approximation and guess.
I agree that it makes business sense to shift risk to the potential employee.
My observation is that this biases the employment pool toward those who have extra money and time to work for no income.
Those who have to work two jobs, or spend their free time taking care of chronically ill family, or are otherwise prevented from being able to work for free, have less of a chance, even if they are otherwise well-qualified.
I have no suggestions for what to change, only my original comment that "passion" seems altogether too often a code phrase for something other than "loves to program."
I can understand the motivation from the perspective of recruiters, but I'd really hate to see STEM fields be infiltrated with the filth of unpaid internships that is unfortunately so common in many other fields.
Being Open Source developer myself, i know the feeling/stress of a community. However, being able to work on my working time almost exclusively on my projects, helped me to have a normal life after the working hours. So I guess the problem is not being able to sell your idea to your company internally. I'm sure Twitter would support this idea.
The funniest part is when there are accusations upon them for discriminating / not hiring women. Not only they do a selfish contribution to society for next to nothing in return, they also need to share whatever credit they earn with some self-appointed victims of sexual discrimination.
I have a very simple rule when it comes to doing work, be it on open source software or otherwise. If you want me to do something for you, (and you are not a close friend or relative) you will pay me appropriately for it. Want me to fix a bug for you? Pay me. Want me to merge your drive by pull request? Pay me. Want "to arrange a zoom call between me and your team to discuss how we can better use your project to add value to our business". Pay me. This idea that we should all be giving away our labour in the name of the great God's FLOSS and freedom is bollocks and one of the great con jobs of late stage capitalism.
Open source hackers suffer the same fate as other creatives. What's the software industry analog of gigging at some shit bars that rake in money getting people who like your music drunk but not paying you all while working a day job so you can do what you love?
Really it's this whole stupid capitalist setup. It's not just open source programmers and artists who suffer this. It's everyone. Have you ever met a single parent who works full time just so they can be a parent full time? Which, by the way, is probably the most important work someone can do, parenting.
> Open source hackers suffer the same fate as other creatives. What's the software industry analog of gigging at some shit bars that rake in money getting people who like your music drunk but not paying you all while working a day job so you can do what you love?
Agree.
> Really it's this whole stupid capitalist setup.
Disagree. Capitalism is a viable prospect, perhaps the only one that won't be bastardized by randoms at some level of economic activity. However, it should be kept in check in some form. I like the idea of UBI personally, but there are other alternatives.
In addition to UBI, which would give labourers more bargaining power with employers, some regulation is needed (Environmental, GDPR), but should be written with input from subject matter experts.
I'm open to having my mind changed on any of the above, but this is the conclusion I've drawn at this point.
If you’re part of some group (e.g., OSS contributors), and a mass media propaganda company, like Wired, which is run by a Vanderbilt, comes along and starts saying things about “this poor lil feller is being abused”, etc., you should be extremely worried; they work for somebody who’s coming after you.
The first step in taking advantage of a group else is convincing that group that they’re victims.
Well my friend, the soil where you're trying to plant your sensible words is just totally barren. Here on HN you'll most probably face feedback only from those who work exactly for somebody who's coming after some group as you say, or zealous dupes who follow the former for free. And that feedback will never be positive!
