Writing new features is fun. Polishing is boring and thankless, aka work. Most people will do fun things for free but want to be paid for work. Probably not going to change anytime soon.
Judgement goes both ways. Maintainers are under no obligation to accept my code, but if enough maintainers stonewall enough of my code for reasons that I consider unreasonable enough then I'm under no obligation to write the code, either. That's where I've gotten to. It wasn't a short journey. Oh well.
If you add the missing feature to a fork, nothing stops you from making use of that code directly. You aren't dependent on the author merging things upstream. You never were.
seems like a self furfilling prophecy, no? if you don't care about the feature but also make it impossible for others to reasonably enter and care for you, all you're left with is a broken window.
Maybe the onboarding is the real issue. There aren't a lot of people around who can dedicate themselves to simply educating new contributors (clearly the "educate yourself" approach doesn't work, based on your experience). the maintainers are too busy to do that themsevles most of the time, so that means it's another dedicated position to fill.
But alas, no one wants to pay for teachers. Teachers don't produce immediate value but are being immediately paid. How wretched. Even tech isn't immune to such philosophy.
Maybe. Or maybe I'm left with a building that works fine for me. It might be lacking some features that some people want, but maybe thats ok.
> Maybe the onboarding is the real issue. ... the maintainers are too busy to do that themselves most of the time.
Yeah; I saw a great talk from Strange Loop the other day by the developer of Elm on the economics of opensource software[1]. He pointed out that a "good" opensource project really wants good dev work, a maintained issue tracker, infrastructure (CICD, etc), a good website, documentation, blog posts, onboarding of devs, community stuff, conference talks, trademarks, a roadmap, and so on. But it takes more than one person to do all of that. It takes a whole team.
And we're spoiled by opensource projects like React or Rust which are sponsored by companies with money. My little opensource projects just have me, in my hobbyist time. And I'm not very good at all the non-programming things. And I'd much rather be programming than doing all of that other stuff.
I think a lot of projects really want fulltime maintainers. But instead they just have the unpaid, overworked authors doing what we can. Of course users want better. But, well, thats how it is at the moment. Honestly, its surprising that everything works as well as it does.
that's fair and respectable. I'm never going to harp on a volunteer for "not working hard enough".
But we can also apply the same logic to projects like GIMP. It's still active so it's not like they haven't heard the decades of feedback on UI/UX.
>And we're spoiled by opensource projects like React or Rust which are sponsored by companies with money. My little opensource projects just have me, in my hobbyist time.
I think most of the criticism comes from the larger projects that have those maintainers but act as gatekeepers against project. Of course I'm not going to hold it against a small repo maintained by 1-2 people if they don't merge in all the PRs. I'm more likely to simply fork the project if I really need it and maintain my own specific fixes/enhancements in those cases.
Three examples:
- Linux mint start menu isnt able to perform basic numerical computations. I made some simple changes to be as ble to do that, and made a PR.
- A Mint desklet showing pics didn't show the file location, I added that functionality. Pr done as well
- A Mint tray icon Applet for crypto was missing some functionality I wanted (dont remember what). I added it and made a PR.
The first two PRs were rejected for whatever reasons. The last one was accepted and merged.
I couldn't care less about the first two, I made the code for me and it works for me. I just put it there in case the owners found it useful. If not, I dont care.
Nobody is getting paid to do open source, there may be people who like the "fame", but myself? I just want to solve my problems.
it's more for the sake of "pay it forward" in my head. if I think a feature or fix will benefit others, of course I want to share that. But if the gatekeepers don't care or see eye to eye, I'm not gonna spend hours arguing over it.
If its a minor enough add/fix, I'll simply point others to the PR to grab themselves if they hit the same issue as me.
>myself? I just want to solve my problems.
maintaining my own branch adds more overhead when updating though. Not enough to go through the politics, but enough for me to at least try to throw a bone at Main first.
I don’t really know of a good strategy for dealing with this in FOSS. If a feature contributor doesn’t care about polish, and you say to them ‘please fix the UX’, they can just either ignore the feedback (‘perfect is the enemy of good! move fast and break things!’), or if they don’t have direct commit access, create a fork that they can then advertise as having lots of cool new features.
I would love to know some strategies that work to strike a balance between not demanding perfection and not allowing garbage to be mainlined.
That has to come from the top of the project's management though, since they're ultimately the ones responsible for policy and enforcement.
My approach would be as I mentioned elsewhere: allow those wanting to contribute new features to do so, but make it clear that these features will be present in prerelease builds only until their quality meets the project's standards.
expecting an artist to be a good programmer or a programmer to be a good artist is just unrealistic. not a lot of artist attracted to FOSS/github/projects to go looking for things to do. probably a much better result from FOSS maintainers to jump onto Fivr and look for someone to do polish
It happens sometimes but the aforementioned difference in mentality usually ends up with those artists giving up and moving on because of the friction involved.