4 ms·

> The open source maintainer problem isn’t going to get much better in the near future. People are gonna keep blaming “Capitalism” for this. People are gonna ke

by nisa 5y ago

> The open source maintainer problem isn’t going to get much better in the near future. People are gonna keep blaming “Capitalism” for this. People are gonna keep blaming “Capitalism” for a lot of irrelevant things. People are gonna argue with me about blaming “Capitalism”. Goddamn I am so tired of “the problem is CAPITALISM” takes and they will never stop The entitlement and arrogance is pretty mind-blowing - those damn' developern don't fix our bugs, don't always respond fast for security updates - such a big problem, but wait - maybe not such a big problem to actually task a dev from my company to work on the dependency - either by maintaining a local fork or helping upstream. Because oh well - this costs actually money. Sure blaming capitalism is oversimplifying the problem but it's pretty clear that most companies try to avoid using their resources for improving important open-source components. I don't mean paying the developers - that doesn't always work but instead doing things like upstreaming bugfixes and features, maintaining a local fork if upstream is not responsive or even publishing an improved fork. It happens but not very often.

afarrell 5y ago
The problem is that there’s no agreed-upon point when we give FOSS maintainers the negotiating power to get the compensation they actually need —- whether that is patches or pesos.
- nisa 5y ago
  I argue that a healthier approach would be to own the foss-components you use and to try to build an internal understanding of them - no need to audit every line of code but at least some high-level understanding what every component does would already be helpful - try asking for resources to do so, I guess most of the time you will be laughed at. Also giving your devs the knowledge and time to upstream fixes until the maintainer is happy would be great - so many interesting forks and pull requests in all kinds of projects that are just dumped out there but the work to integrate it into upstream is something nobody is doing. This requires resources and resources are money and there is no direct benefit for the corporation. So it's quite a big problem.
  - afarrell 5y ago
    You’ve reframed the problem — have you made it larger or smaller? Which problem requires a smaller team to achieve: A. Training a high enough software engineers in the negotiating skills that they could get the time to develop that understanding. I estimate that training 80,000[1] developers to do this would require 3-6 years from a team of at least 1,000 people with tech lead level of experience… it would likely also need to be repeated every 2 years as new people join the industry. B. Establishing a social norm that sets the default choices of debates in lots of companies. Baking that social norm into the structure of tools like npm and github. I estimate this would take 1-5 years from 10-30 people with leadership experience and political capital in developer relations/marketing and sales engineering. [1] https://insights.stackoverflow.com/survey/2021 https://insights.stackoverflow.com/survey/2021

by nisa 5y ago

afarrell 5y ago

The problem is that there’s no agreed-upon point when we give FOSS maintainers the negotiating power to get the compensation they actually need —- whether that is patches or pesos.

nisa 5y ago
I argue that a healthier approach would be to own the foss-components you use and to try to build an internal understanding of them - no need to audit every line of code but at least some high-level understanding what every component does would already be helpful - try asking for resources to do so, I guess most of the time you will be laughed at. Also giving your devs the knowledge and time to upstream fixes until the maintainer is happy would be great - so many interesting forks and pull requests in all kinds of projects that are just dumped out there but the work to integrate it into upstream is something nobody is doing. This requires resources and resources are money and there is no direct benefit for the corporation. So it's quite a big problem.
- afarrell 5y ago
  You’ve reframed the problem — have you made it larger or smaller? Which problem requires a smaller team to achieve: A. Training a high enough software engineers in the negotiating skills that they could get the time to develop that understanding. I estimate that training 80,000[1] developers to do this would require 3-6 years from a team of at least 1,000 people with tech lead level of experience… it would likely also need to be repeated every 2 years as new people join the industry. B. Establishing a social norm that sets the default choices of debates in lots of companies. Baking that social norm into the structure of tools like npm and github. I estimate this would take 1-5 years from 10-30 people with leadership experience and political capital in developer relations/marketing and sales engineering. [1] https://insights.stackoverflow.com/survey/2021 https://insights.stackoverflow.com/survey/2021