The Few, the Tired, the Open Source Coders
wired.com
wired.com
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.
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.
... 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.
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.
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?
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.
This does not seem reasonable to me. I would think the number of abandoned open source projects to be closer to 70% or higher.
Even projects that have reached popularity.
So many times I have found references to libraries I wanted to use (C#/F# .Elixir).
In the end I find a link to sourceforge or similar to find it has been abandoned-ware for a long time.
Then we have the vast majority of open source code that never reached much of an audience and have been abandoned long ago.
I am sure if one ran a query over all public GitHub, Gitlab, Bitbucket, SourceForge, Codeproject the vast majority are abandoned.
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.
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.
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".
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).
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.
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 know myself, when I put something in open source I feel a responsibility to maintain it for no reasonable reason.
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").
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).
- 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?
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.
What happened to them?
! 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.spacerIf 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.
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.
I'm curious what you mean.
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.
[0] https://goteleport.com/blog/kubernetes-kustomize-kep-kerfuff...
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.
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.
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?
With this model, the fees could increase with each distribution platform your project depends on.
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)
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."
They have made significant contributions
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.
The first step in taking advantage of a group else is convincing that group that they’re victims.