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?
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 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.
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.
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.
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 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.
> "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.
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.
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.)
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.
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.
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 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".
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
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.
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.)
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.
I think it should be easier to make "mods" to existing codebases. I tried, once: https://github.com/liolaarc/monki (jeez, 5 years ago now.)
It's basically a git clone + a literate programming file that describes what changes to make to the code. It worked pretty well, though I often wonder whether it was just some silly idea.
So essentially, if you wanted to apply a fix to an open source codebase locally for your business, you could do that. It would be a clone, followed by a patch. (In this context, a "patch" is simply "here's the existing code I expect; here's the new code to replace it with." It works until that specific code changes at some point in the future.)
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.
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 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.
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.
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.
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.
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.
> 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.
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...
> 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.
> 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.
> “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.
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.
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:
> 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.
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.
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.
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.
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.
When there are only vipers and toads in a barrell, warm-blooded creatures are few and go by throwaway accounts :)
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!
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.
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).
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.
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.
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 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.
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."
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.
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.
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.
172 comments
[ 3.6 ms ] story [ 227 ms ] threadhttps://github.com/fossjobs/fossjobs/wiki/Resources
https://www.business.com/articles/john-rampton-open-source-s...
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.
https://news.ycombinator.com/item?id=25040397
They have made significant contributions
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.
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.
https://opensource.org/osd - "No Discrimination Against Fields of Endeavor" includes "it may not restrict the program from being used in a business".
"paid support" means you have to make sure your software is good enough to use and crappy enough to need support.
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 then got paid twice. After 9 months and multiple inquiries I still don't know how to give them their money back!
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 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.
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.
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.
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.
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.)
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".
What happened to them?
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.
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."
raiser: table flip
> 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.
It's basically a git clone + a literate programming file that describes what changes to make to the code. It worked pretty well, though I often wonder whether it was just some silly idea.
So essentially, if you wanted to apply a fix to an open source codebase locally for your business, you could do that. It would be a clone, followed by a patch. (In this context, a "patch" is simply "here's the existing code I expect; here's the new code to replace it with." It works until that specific code changes at some point in the future.)
I think we still need people paying open source contributors.
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.
Cypress not responding to emails to orchestrate the PR isn't helping either
Oh there's a bug in this or that edge case? Please send a pull request and I'll consider it.
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).
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.
I've succeeded at 1 & 2 and failed at 3.
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.
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.
Not sure why your downvoted, this is very true in my experience.
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.
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.
I suspect being an open source project maintainer is a self selecting grind.
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.
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.
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.
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.
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.
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.
[0] https://github.com/ChrisMarshallNY#github-stuff
... or, in theory, to turn your hobby into your work, which I'm sure somebody would like (i.e. me, but somehow in 20 years it has never happened).
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...
Pretty much for the same reasons as open source developers are the same.
https://en.wikipedia.org/wiki/Overjustification_effect
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 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. Frankly OSS wouldn't have gotten this far if that wasn't the case.
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.
That's an attitude problem on the part of the developer. He shouldn't feel guilty for providing insufficient free support.
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.
They chose to depend solely on me. They, and not I, are responsible for their decisions.
https://www.fordfoundation.org/work/learning/research-report...
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.
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.
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.
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.
I know myself, when I put something in open source I feel a responsibility to maintain it for no reasonable reason.
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?
[1] https://youtu.be/o_4EX4dPppA
https://news.ycombinator.com/item?id=22824899
The first step in taking advantage of a group else is convincing that group that they’re victims.
When there are only vipers and toads in a barrell, warm-blooded creatures are few and go by throwaway accounts :)
Open Source maintainers owe nothing to non-paying users. The norm should be that only those that pay get support.
"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.
> 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.
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.
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).
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.
It might even improve our code.
"Random acts of open source compensation."
(comment has been edited for clarity)
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.
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.
From a business standpoint, it makes sense as it shifts risk to the potential employee.
But like having unpaid interns, it biases the employment pool toward those who have extra money and time to work for no income.
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.
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.
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.
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.
Everything in an interview process is an approximation and guess.
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."
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?
0: https://www.npmjs.com/package/left-pad
With this model, the fees could increase with each distribution platform your project depends on.
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.
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.
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.
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'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.