The problem being that as a maintainer, I refuse most contributions. Not only because they are low-quality (it happens), but also because they are often out of scope, or I just disagree with the direction. It's my project, I maintain it, I choose what goes in it. But you're free to fork it with your changes, that's exactly why I made it open source. If you make an interesting fork, I may totally import some or all of your changes! And if you first ask in an issue, I may offer you to open a PR directly.
I almost always use copyleft licences: it makes it mandatory to share the modified sources with the user, who can then upstream them.
Many times in companies, if I need to patch a permissive dependency, my company will not allow me to spend time upstreaming my patch. Whereas if it is a copyleft licence, I can tell my manager that I am obligated to open source my changes (which is not correct, but managers usually don't know that, don't care so much about the nuance, and anyway it's a win if we follow the copyleft conditions to the letter).
I'd argue all merge requests matter, not only those that were accepted upstream. Sure, only those accepted generate value upstream, but there is a lot of byproduct from a rejected MR that still has value, either as a reference for further discussions or as resource for forks.
But my experience has been that most managers are not competent in that regard. If you have a good manager that understands that, then that's great. But it's rare. Most of the time, it works better to bullshit them with the legal consequences of not allowing you to upstream your changes.
I don't think dropping a random software developer into a random project to do their open source duty would end well
It takes a _lot_ of time for someone to meaningfully contribute to a project, and would just result in maintainers having the overhead of training that many new people on a project
I'd much rather figure out a way to finance those open source projects in a sustainable way where those projects can decide to hire full time employees.
Completely agree. I'd rather have the people that want to be there, to be involved.
An alternative take I'd rather see is "Employers guarantee 8 hours per week of time to work on open-source projects, including ones I start myself". Employer gets no IP stake in the project, and it's done for public good + a means to allow employees to upskill.
Otherwise it just becomes a case of another grindset. You're expected to do more, with the limited free time you have.
I get that the author is making a "modest proposal" here, but even so it's kind of antithetical to at least my own feelings about open source. If I release something as open source, the whole point is my users owe me nothing. They have limited obligations that are explicitly spelled out in the license and that's it.
Sure but the real problem are the companies that consume, not just the developers. A lot of developers would love to contribute back, but companies put schedule pressures and have limited interest in contributing back.
Companies actually want a kind of vendor relationship, but they don’t want to pay any money.
Devs want something dev focused, and open source is usually code for being dev focused.
I don’t think either truly wants actual “open source”
Readit News
The problem being that as a maintainer, I refuse most contributions. Not only because they are low-quality (it happens), but also because they are often out of scope, or I just disagree with the direction. It's my project, I maintain it, I choose what goes in it. But you're free to fork it with your changes, that's exactly why I made it open source. If you make an interesting fork, I may totally import some or all of your changes! And if you first ask in an issue, I may offer you to open a PR directly.
I almost always use copyleft licences: it makes it mandatory to share the modified sources with the user, who can then upstream them.
Many times in companies, if I need to patch a permissive dependency, my company will not allow me to spend time upstreaming my patch. Whereas if it is a copyleft licence, I can tell my manager that I am obligated to open source my changes (which is not correct, but managers usually don't know that, don't care so much about the nuance, and anyway it's a win if we follow the copyleft conditions to the letter).
But my experience has been that most managers are not competent in that regard. If you have a good manager that understands that, then that's great. But it's rare. Most of the time, it works better to bullshit them with the legal consequences of not allowing you to upstream your changes.
Again, that's my experience.
It takes a _lot_ of time for someone to meaningfully contribute to a project, and would just result in maintainers having the overhead of training that many new people on a project
I'd much rather figure out a way to finance those open source projects in a sustainable way where those projects can decide to hire full time employees.
An alternative take I'd rather see is "Employers guarantee 8 hours per week of time to work on open-source projects, including ones I start myself". Employer gets no IP stake in the project, and it's done for public good + a means to allow employees to upskill.
Otherwise it just becomes a case of another grindset. You're expected to do more, with the limited free time you have.
It’s like the strategic difference between relying on a volunteer army vs conscription
Deleted Comment
System: "Contributing to Open-Source Should be Required, Like Jury Duty"
> No One Understands Software Because No One Understands Time
> All Programming Languages Converge to English Eventually
> The Best Database Is Just Two People Talking
> Stop Writing Code. Start Legislating Software
And my personal favorite:
> AI Safety Is Just the New Gluten-Free
Dead Comment
Companies actually want a kind of vendor relationship, but they don’t want to pay any money.
Devs want something dev focused, and open source is usually code for being dev focused.
I don’t think either truly wants actual “open source”