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.
How much would it cost to fund, say, all Github projects with 1000 stars or more?
The Few, the Tired, the Open Source Coders
61–70 of 173 posts
Re: The Few, the Tired, the Open Source Coders
#62Rather 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.
It might even improve our code.
"Random acts of open source compensation."
(comment has been edited for clarity)
Re: The Few, the Tired, the Open Source Coders
#63> “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.
Re: The Few, the Tired, the Open Source Coders
#64Earlier quoted context omitted.
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…
I agree this is a great way to sell it, but don’t all the dead end forks of Linux for various ARM SoCs belie the Linux argument?
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.
Re: The Few, the Tired, the Open Source Coders
#65Open 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 p…
> 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.
Re: The Few, the Tired, the Open Source Coders
#66There'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,…
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.
Re: The Few, the Tired, the Open Source Coders
#67The article fails to mention new companies that are trying to solve this problem, e.g. https://tidelift.com
Re: The Few, the Tired, the Open Source Coders
#68It 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 hel…
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.
Re: The Few, the Tired, the Open Source Coders
#69Earlier quoted context omitted.
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 maintain…
>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 sing…
Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.
Re: The Few, the Tired, the Open Source Coders
#70It 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 hel…
Um... 3) More than market. They put in the upfront and just liked businesses expect, there should be return.
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).