3 ms·

> I've had times when I'm pressured to do a bug fix on a 5 year old project where I don't even remember how it works or review and merge an enthusiastic PR solv

by esperent 10mo ago

> I've had times when I'm pressured to do a bug fix on a 5 year old project where I don't even remember how it works or review and merge an enthusiastic PR solving a problem I don't actually care about. Also having spent years working in the OSS space, I wish it was normalized to have more nuance between "totally unmaintained" and "maintainer will literally miss their child's birthday to review your PR". There's already all kinds of badges on GH readmes, couldn't we have a few more signifying "actively maintained, PRs welcome" or "security & critical bug fixes only" or "looking for new maintainers", etc.?

blitzar 10mo ago
"when your fix is accepted you are the new maintainer"
- ozim 10mo ago
  That's what we do in closed source corporate code.
  - CatMustard 10mo ago
    "Hi, I see you're the owner of this 6000-line mess of a component, could you answer some questions for me?" "I don't own it, I didn't write it, and I don't understand it even slightly. I just made a one-line bug fix for one function in it a year ago and nobody has touched it since, so my name is on top of the git history." "Cool, so as the owner could you tell me..."
    - sph 10mo ago
      I like this, turning software maintenance into a long-running game of tag.
      - zrail 10mo ago
        I like to refer to it as the cooties ownership model. I.e. once you touch it you have cooties.
        ozim 10mo ago
        we call it stinky egg.
    - saghm 10mo ago
      I'd be tempted to try to trick them into merging a small change so then they're the new owner and have to figure it out themselves.
      - CatMustard 10mo ago
        The Passing of the Curse
    - Isamu 10mo ago
      Yeah at work I’m paid to own some components that I didn’t write and don’t entirely understand, so I figure my job is to help discover answers for the questions that arise. I would not want to be a public maintainer though. I don’t have the patience or motivation to use my spare time for that.
    - didgetmaster 10mo ago
      Makes you wonder if the reason why some trivial bug in a closed source project goes unfixed for years; is because all the engineers are afraid to touch the code in some obscure library and instantly become its new 'owner'.
      - ozim 10mo ago
        Mostly it is that you don’t go around fixing random stuff. You might actually get in trouble picking up stuff that is not a priority. Company I work for is less strict so we do “fix anything Friday”. But for some other companies you might get a slap on the wrist for not following the plan and product owners pick what gets fixed and what not based on business plan. If there are big customers nagging - bug will be fixed asap.
- darubedarob 10mo ago
  "Pikaboo maintainer is who last touched it. Patch is wellcome!"
- Aurornis 10mo ago
  Jia Tan has entered the chat. (Jia Tan was the alias used by the group that backdoored XZ utils by becoming a maintainer) My other comment in this thread has more details, but in my experience it’s more common to encounter projects that don’t want new maintainers or forks. They’re happy with the status quo with their name at the top but also don’t want to let go of control or see competing forks created.
- ErroneousBosh 10mo ago
  That's how I ended up with FlaskBB I guess.
Aurornis 10mo ago
> Also having spent years working in the OSS space, I wish it was normalized to have more nuance between "totally unmaintained" and "maintainer will literally miss their child's birthday to review your PR". The other spectrum that I’d like to know up front is where the maintainers fall on the spectrum of “I would be honored if you forked my project” to “This project is my baby and I will mobilize my users against you if you fork it”. The refrain with open source is always that if you don’t like something, you’re welcome to fork it. But my experience with forking projects has, in a couple cases, drawn anger and attacks from maintainers. In a corporate setting when we ran up against maintainers who were unable or uninterested in even merging PRs, we had to fork the project and continue work in the fork. For some maintainers, this turns into “<corporation> is trying to steal my work!” even when the name and README were maintained. Or the maintainer gets angry that the name is kept on the fork because it is no longer under their control, we changed the name, which prompted more anger because we were “stealing their project” and so on. To be completely clear, this isn’t all maintainers. Some have been so happy that they marked their original as maintained and referred users to the new fork in the README. But I’ve had enough cases where forking triggered anger or even calls to mobilize their Discord against the fork across social media (HN, Reddit, Mastodon) that when I run up against a slowly-maintained OSS project I try to look for alternatives or evaluate the effort to just build it in house to avoid drama.
- didgetmaster 10mo ago
  I wonder how effective it is for an OSS maintainer to try to prevent someone from 'stealing their project' when <corporation> doing the fork is huge with plenty of resources (engineering, marketing, and legal) vs just some startup that is trying to gain some traction.
  - ranger_danger 10mo ago
    In my experience with exactly what parent comment discussed... it's not effective. In fact, the company may even (which I have witnessed personally multiple times) blatantly violate your OSS license to incorporate it into their proprietary money-making product, because they know they can get away with it... most lone devs do not have the money or willpower to attack a corporation, even if they could win. Usually I see those lone devs either ignoring them entirely, or ragequitting open-source altogether.

blitzar 10mo ago

"when your fix is accepted you are the new maintainer"

ozim 10mo ago
That's what we do in closed source corporate code.
- CatMustard 10mo ago
  "Hi, I see you're the owner of this 6000-line mess of a component, could you answer some questions for me?" "I don't own it, I didn't write it, and I don't understand it even slightly. I just made a one-line bug fix for one function in it a year ago and nobody has touched it since, so my name is on top of the git history." "Cool, so as the owner could you tell me..."
  - sph 10mo ago
    I like this, turning software maintenance into a long-running game of tag.
    - zrail 10mo ago
      I like to refer to it as the cooties ownership model. I.e. once you touch it you have cooties.
      - ozim 10mo ago
        we call it stinky egg.
  - saghm 10mo ago
    I'd be tempted to try to trick them into merging a small change so then they're the new owner and have to figure it out themselves.
    - CatMustard 10mo ago
      The Passing of the Curse
  - Isamu 10mo ago
    Yeah at work I’m paid to own some components that I didn’t write and don’t entirely understand, so I figure my job is to help discover answers for the questions that arise. I would not want to be a public maintainer though. I don’t have the patience or motivation to use my spare time for that.
  - didgetmaster 10mo ago
    Makes you wonder if the reason why some trivial bug in a closed source project goes unfixed for years; is because all the engineers are afraid to touch the code in some obscure library and instantly become its new 'owner'.
    - ozim 10mo ago
      Mostly it is that you don’t go around fixing random stuff. You might actually get in trouble picking up stuff that is not a priority. Company I work for is less strict so we do “fix anything Friday”. But for some other companies you might get a slap on the wrist for not following the plan and product owners pick what gets fixed and what not based on business plan. If there are big customers nagging - bug will be fixed asap.
darubedarob 10mo ago
"Pikaboo maintainer is who last touched it. Patch is wellcome!"
Aurornis 10mo ago
Jia Tan has entered the chat. (Jia Tan was the alias used by the group that backdoored XZ utils by becoming a maintainer) My other comment in this thread has more details, but in my experience it’s more common to encounter projects that don’t want new maintainers or forks. They’re happy with the status quo with their name at the top but also don’t want to let go of control or see competing forks created.
ErroneousBosh 10mo ago
That's how I ended up with FlaskBB I guess.

Aurornis 10mo ago

> Also having spent years working in the OSS space, I wish it was normalized to have more nuance between "totally unmaintained" and "maintainer will literally miss their child's birthday to review your PR". The other spectrum that I’d like to know up front is where the maintainers fall on the spectrum of “I would be honored if you forked my project” to “This project is my baby and I will mobilize my users against you if you fork it”. The refrain with open source is always that if you don’t like something, you’re welcome to fork it. But my experience with forking projects has, in a couple cases, drawn anger and attacks from maintainers. In a corporate setting when we ran up against maintainers who were unable or uninterested in even merging PRs, we had to fork the project and continue work in the fork. For some maintainers, this turns into “<corporation> is trying to steal my work!” even when the name and README were maintained. Or the maintainer gets angry that the name is kept on the fork because it is no longer under their control, we changed the name, which prompted more anger because we were “stealing their project” and so on. To be completely clear, this isn’t all maintainers. Some have been so happy that they marked their original as maintained and referred users to the new fork in the README. But I’ve had enough cases where forking triggered anger or even calls to mobilize their Discord against the fork across social media (HN, Reddit, Mastodon) that when I run up against a slowly-maintained OSS project I try to look for alternatives or evaluate the effort to just build it in house to avoid drama.

didgetmaster 10mo ago
I wonder how effective it is for an OSS maintainer to try to prevent someone from 'stealing their project' when <corporation> doing the fork is huge with plenty of resources (engineering, marketing, and legal) vs just some startup that is trying to gain some traction.
- ranger_danger 10mo ago
  In my experience with exactly what parent comment discussed... it's not effective. In fact, the company may even (which I have witnessed personally multiple times) blatantly violate your OSS license to incorporate it into their proprietary money-making product, because they know they can get away with it... most lone devs do not have the money or willpower to attack a corporation, even if they could win. Usually I see those lone devs either ignoring them entirely, or ragequitting open-source altogether.