4 ms·

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or

by dolmen 16d ago

From the article: > So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there. We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load and risk of breaking an old codebase that so many users depend on. Deprecating the project is playing the open source game in an other dimension: tell the word that depending on this project was a bad idea in the first place and that everyone should move on. But releasing a fix on a deprecated project is fine too. So both actions are on different dimensions, this isn't a choice between 2 options.

jjice 16d ago
The man released a fix twelve years ago for free. If someone is really depending on this, they can fork it themselves. I'd argue that that's the beauty of open source, rather than a downside.
mech422 16d ago
The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.
- lukeify 16d ago
  Others would say pragmatic.
- iso1631 16d ago
  I think it shows a complete misunderstanding on what free software is.
  - dspillett 16d ago
    Free software is Free (and free software is free, libre software is libre, …, where the free/Free/libre/OS/… distinctions are relevant). That does not guarantee continued maintenance for decades, and to expect such is the sort of entitlement that puts some people off sharing their work and playthings.
  - reichstein 16d ago
    Can you explain what that misunderstanding is? Deprecation is just a tag. You don't have to respect it. And if you want the project to continue, you can freely fork it.
- dspillett 16d ago
  It doesn't say that depending on it was a bad idea, but that depending on it going forward is a bad idea, and they've gone the extra mile and made an announcement including information about what better alternatives are not available. Would you prefer it just sat there unfixed and unsupported?
  - mech422 16d ago
    that is NOT what it says - "tell the word that depending on this project WAS a bad idea" ... 'was' - past tense, as in depending on it in the past was a bad idea
post-it 16d ago
Why don't you do it?
serial_dev 16d ago
We are in the AI era, it doesn't change the fact that investing 1 hrs a month (or even a week) into a long-dead project in a language you no longer use is more investment than 0 hours for the rest of your life. And yes, if your timeline as a dependency enjoyer is "is this project going to be maintained for 15 years" and you still assumed the answer is yes, it's kind of on you adding a dependency.
dspillett 16d ago
Even with AI, the result needs to be reviewed both to make sure it is actually correct in what it intends to do and that it does not have knock-on effects anywhere else. Given the description of the bug I'd think that spinning up the AI and pointing it in the right direction would save no time over just fixing the issue completely by hand. Fixing the issue could set an expectation in current users of the package that it might get updates going forward, which it obviously won't from this maintainer, potentially reducing any impetus that might exist to move over to something that is a more correct solution these days. Handing over control of the project where it is has risks which are stated in TFA. So while both fixing and deprecating could have been done, I think the right choice (just mark it as deprecated) has been made. Not fixing the existing bug(s) will not break anything that is using the package any more than it is already broken. If one of the existing issues had potential to be a security issue then I might err more towards fix+deprecate (with big red text included in any announcement of the fix to the effect that this is the last one and future issues won't get resolved upstream).
nkrisc 16d ago
The cool thing about open source is anyone can fork it and spend their own money asking AI to make a fix.
notourproblem 16d ago
> check what it proposes This requires re-learning the language he's out of practice with.

by dolmen 16d ago

jjice 16d ago

The man released a fix twelve years ago for free. If someone is really depending on this, they can fork it themselves. I'd argue that that's the beauty of open source, rather than a downside.

mech422 16d ago

The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.

lukeify 16d ago
Others would say pragmatic.
iso1631 16d ago
I think it shows a complete misunderstanding on what free software is.
- dspillett 16d ago
  Free software is Free (and free software is free, libre software is libre, …, where the free/Free/libre/OS/… distinctions are relevant). That does not guarantee continued maintenance for decades, and to expect such is the sort of entitlement that puts some people off sharing their work and playthings.
- reichstein 16d ago
  Can you explain what that misunderstanding is? Deprecation is just a tag. You don't have to respect it. And if you want the project to continue, you can freely fork it.
dspillett 16d ago
It doesn't say that depending on it was a bad idea, but that depending on it going forward is a bad idea, and they've gone the extra mile and made an announcement including information about what better alternatives are not available. Would you prefer it just sat there unfixed and unsupported?
- mech422 16d ago
  that is NOT what it says - "tell the word that depending on this project WAS a bad idea" ... 'was' - past tense, as in depending on it in the past was a bad idea

post-it 16d ago

Why don't you do it?

serial_dev 16d ago

We are in the AI era, it doesn't change the fact that investing 1 hrs a month (or even a week) into a long-dead project in a language you no longer use is more investment than 0 hours for the rest of your life. And yes, if your timeline as a dependency enjoyer is "is this project going to be maintained for 15 years" and you still assumed the answer is yes, it's kind of on you adding a dependency.

dspillett 16d ago

Even with AI, the result needs to be reviewed both to make sure it is actually correct in what it intends to do and that it does not have knock-on effects anywhere else. Given the description of the bug I'd think that spinning up the AI and pointing it in the right direction would save no time over just fixing the issue completely by hand. Fixing the issue could set an expectation in current users of the package that it might get updates going forward, which it obviously won't from this maintainer, potentially reducing any impetus that might exist to move over to something that is a more correct solution these days. Handing over control of the project where it is has risks which are stated in TFA. So while both fixing and deprecating could have been done, I think the right choice (just mark it as deprecated) has been made. Not fixing the existing bug(s) will not break anything that is using the package any more than it is already broken. If one of the existing issues had potential to be a security issue then I might err more towards fix+deprecate (with big red text included in any announcement of the fix to the effect that this is the last one and future issues won't get resolved upstream).

nkrisc 16d ago

The cool thing about open source is anyone can fork it and spend their own money asking AI to make a fix.

notourproblem 16d ago

> check what it proposes This requires re-learning the language he's out of practice with.