6 ms·

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 goi

by qzw 3y ago

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.

jjoonathan 3y ago
Writing is fun, polishing is boring but ok, merge politics is like burning in the pits of hell. Same result.
- jahnu 3y ago
  Sometimes getting a contribution into a FOSS project is more difficult than proving your application will halt.
  - josephg 3y ago
    And for good reason. If you swoop in and add a feature I (as the maintainer) don’t care about, the maintenance burden for that code usually falls to me. I don’t want to spend my time maintaining someone else’s code for a feature I don’t care about. So yeah, I have higher standards for testing and code quality for 3rd party contributors than I have for my own code. I like PRs which fix bugs. But PRs which add features, without talking them through first? Ehhhhh
    - jjoonathan 3y ago
      Sure, but that's why I mentioned politics -- the particulars matter and there is plenty of ground for reasonable people to disagree. 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.
      - josephg 3y ago
        Yeah. I think deep down opensource doesn't rest on the ability to make pull requests. It rests on the ability to fork. I think maybe people should do that more often. 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.
    - johnnyanmac 3y ago
      >I don’t want to spend my time maintaining someone else’s code for a feature I don’t care about. 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.
      - josephg 3y ago
        > if you don't care about the feature ... all you're left with is a broken window. 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. [1] https://www.youtube.com/watch?v=XZ3w_jec1v8 https://www.youtube.com/watch?v=XZ3w_jec1v8
        johnnyanmac 3y ago
        >It might be lacking some features that some people want, but maybe thats ok. 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.
  - xtracto 3y ago
    I make open source code for myself. I've done several minor "contributions" to different open source projects. 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.
    - eviks 3y ago
      But solving your problems is easier if your patches are merged, less maintenance burden on your future self
    - johnnyanmac 3y ago
      > there may be people who like the "fame" 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.
jwells89 3y ago
And that's totally fair, but at the same time something of a catch-22. The most well-funded FOSS projects (and thus, those one is most likely to be paid to work on) are generally those that are more polished. What this means to me is that projects need to have a very focused featureset and polish culture from the very beginning to kickstart the virtuous cycle.
evilotto 3y ago
jwz dubbed this "CADT programming"
dylan604 3y ago
it's also a lot to do with the types of people that do polishing/artistic work are very different people from those that do the programming of the features. 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
- jwells89 3y ago
  > not a lot of artist attracted to FOSS/github/projects to go looking for things to do 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.
  - dylan604 3y ago
    a healthy paycheck seems like the only thing that allows the two to work. and a shit load of managerial layering to run interference and cross-translate requests from either side.
csnover 3y ago
There is a secondary issue: Even on projects where someone is interested in doing polish work, since it usually takes longer to polish than to write a new feature, those who only care about writing features cause the backlog of things that need polish to grow infinitely. 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.
- jwells89 3y ago
  This is why I mentioned keeping a smaller, more focused feature set in several of my comments. Polish is much more attainable when features aren't being added as frequently. 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.
nazka 3y ago
I actually love polishing but not writing tests unless it’s with cypress.

by qzw 3y ago

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.

jjoonathan 3y ago

Writing is fun, polishing is boring but ok, merge politics is like burning in the pits of hell. Same result.

jahnu 3y ago
Sometimes getting a contribution into a FOSS project is more difficult than proving your application will halt.
- josephg 3y ago
  And for good reason. If you swoop in and add a feature I (as the maintainer) don’t care about, the maintenance burden for that code usually falls to me. I don’t want to spend my time maintaining someone else’s code for a feature I don’t care about. So yeah, I have higher standards for testing and code quality for 3rd party contributors than I have for my own code. I like PRs which fix bugs. But PRs which add features, without talking them through first? Ehhhhh
  - jjoonathan 3y ago
    Sure, but that's why I mentioned politics -- the particulars matter and there is plenty of ground for reasonable people to disagree. 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.
    - josephg 3y ago
      Yeah. I think deep down opensource doesn't rest on the ability to make pull requests. It rests on the ability to fork. I think maybe people should do that more often. 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.
  - johnnyanmac 3y ago
    >I don’t want to spend my time maintaining someone else’s code for a feature I don’t care about. 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.
    - josephg 3y ago
      > if you don't care about the feature ... all you're left with is a broken window. 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. [1] https://www.youtube.com/watch?v=XZ3w_jec1v8 https://www.youtube.com/watch?v=XZ3w_jec1v8
      - johnnyanmac 3y ago
        >It might be lacking some features that some people want, but maybe thats ok. 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.
- xtracto 3y ago
  I make open source code for myself. I've done several minor "contributions" to different open source projects. 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.
  - eviks 3y ago
    But solving your problems is easier if your patches are merged, less maintenance burden on your future self
  - johnnyanmac 3y ago
    > there may be people who like the "fame" 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.

jwells89 3y ago

And that's totally fair, but at the same time something of a catch-22. The most well-funded FOSS projects (and thus, those one is most likely to be paid to work on) are generally those that are more polished. What this means to me is that projects need to have a very focused featureset and polish culture from the very beginning to kickstart the virtuous cycle.

evilotto 3y ago

jwz dubbed this "CADT programming"

dylan604 3y ago

it's also a lot to do with the types of people that do polishing/artistic work are very different people from those that do the programming of the features. 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

jwells89 3y ago
> not a lot of artist attracted to FOSS/github/projects to go looking for things to do 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.
- dylan604 3y ago
  a healthy paycheck seems like the only thing that allows the two to work. and a shit load of managerial layering to run interference and cross-translate requests from either side.

csnover 3y ago

There is a secondary issue: Even on projects where someone is interested in doing polish work, since it usually takes longer to polish than to write a new feature, those who only care about writing features cause the backlog of things that need polish to grow infinitely. 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.

jwells89 3y ago
This is why I mentioned keeping a smaller, more focused feature set in several of my comments. Polish is much more attainable when features aren't being added as frequently. 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.

nazka 3y ago

I actually love polishing but not writing tests unless it’s with cypress.