Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dumb ways for an open source project to die

nesbitt.io

Post reply on HN
Print view View original

51–60 of 155 posts

Re: Dumb ways for an open source project to die

#51

Post by phyzix5761 »

prymitive wrote: post #26

Call me old but there was a time when “open source project” meant “I had a problem, this is my solution, if someone has the same problem then you are free to use my solution”. These days is more: - building personal brand - showcasing your skills - trying to outsmart somebody else, often because they didn’t merge your pr - sometimes just having fun And if you work for big org it’s also often “this looks vaguely simil…

Its also become lots of people demanding fixes but not many contributing them.

Re: Dumb ways for an open source project to die

#52

Post by aetch »

cebert wrote: post #34
killerstorm wrote: post #32

It's ridiculous that everything is expected to be maintained on a weekly basis. In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later. E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.

Different times. The need to patch for security updates alone is increasing rapidly.

Some things just don’t have security issues found regularly

Re: Dumb ways for an open source project to die

#53

Post by teddyh »

bartread wrote: post #42
tomwheeler wrote: post #2

One that doesn't seem to be listed is "overconfident fork" in which someone forks an existing project out of anger or hubris, but that fork never gains critical mass and eventually withers away. The opposite is what happened with OpenSSH, Jenkins, and LibreOffice, in which the original project (SSH, Hudson, and OpenOffice) had the hubris but was quickly forgotten when the community moved on.

Occasionally though, rather than petering out, you get a rage-fork that does something good. The io.js fork from node back in 2014 or 2015 springs to mind. IIRC there were a bunch of changes/improvements that needed to be made to move node forward and Joyent were dragging their heels (a V8 upgrade might have been one of them but it's been so long I can't remember for sure). Some of the core devs were getting fed up w…

Also the EGCS fork of GCC. That one ended happily, as, IIRC, the EGCS maintainers were assigned (by the GNU project) to be the new official GCC maintainers.

Re: Dumb ways for an open source project to die

#54

Post by zem »

that was a nicely extensive round up of ways a project dies, but I would say that none of them are "dumb". they're all just parts of the software ecosystem's various lifecycles; if anything, they show how many stars need to line up for a project's ongoing success (not to mention how much work needs to be put into it)

Re: Dumb ways for an open source project to die

#55

Post by jonnyasmar »

prymitive wrote: post #26

Call me old but there was a time when “open source project” meant “I had a problem, this is my solution, if someone has the same problem then you are free to use my solution”. These days is more: - building personal brand - showcasing your skills - trying to outsmart somebody else, often because they didn’t merge your pr - sometimes just having fun And if you work for big org it’s also often “this looks vaguely simil…

The framing assumes the ratio of "problem-and-solution" projects to "personal-brand" projects has shifted. I'd push back: I think the underlying ratio is roughly the same — what's shifted is what gets published.

The work of running an open-source project (issue triage, security disclosures, contribution guidelines, CI, release cadence, dependency maintenance) is way higher than the work of solving the original problem. People with the "here's my private workflow tool" mindset increasingly don't publish at all because they can't afford that tax. Meanwhile, anyone seeking brand-building benefits IS willing to take it on, because the brand-building is the point.

So the visible OSS landscape over-represents the brand category not because solution-sharing died, but because solution-sharing acquired a 10x maintenance overhead that most people now opt out of. I see it in my own dotfiles — full of small tools I'd happily share if "share" still meant "drop a gist." It doesn't, anymore.

Re: Dumb ways for an open source project to die

#57

Post by killerstorm »

cebert wrote: post #34
killerstorm wrote: post #32

It's ridiculous that everything is expected to be maintained on a weekly basis. In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later. E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.

Different times. The need to patch for security updates alone is increasing rapidly.

The need for security update is largely due to poor development practices where safe and unsafe code is mixed together, lots of dependencies with unclear provenance and quality, etc.

We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly).

E.g. old way of developing web front-end was like that: you code directly in JS. It never needs to be patched, only browser needs to be patched.

Same thing with Excel/VBA, etc.

But new devs don't know any of that, they just want to use latest "framework" which pre-installs whole bunch of vulns. And if there's a patch you need to rebuild. Constant churn just to satisfy the trend

Re: Dumb ways for an open source project to die

#58

Post by daedrdev »

killerstorm wrote: post #57
cebert wrote: post #34

Earlier quoted context omitted.

Different times. The need to patch for security updates alone is increasing rapidly.

The need for security update is largely due to poor development practices where safe and unsafe code is mixed together, lots of dependencies with unclear provenance and quality, etc. We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly). E.g. old way of developing web front-end was like…

Or in the past code just sat unpatched via obscurity because fewer people were looking. After all there are plenty of exploits from injection to CSS that we have fixed or migrated away from for code from the far past

Re: Dumb ways for an open source project to die

#59

Post by hilariously »

apollyx_jojo wrote: post #37

One pattern I've seen kill smaller open source projects that isn't mentioned: scope creep driven by the most vocal users. A focused tool that does one thing well starts getting PRs and issues for tangential features. The maintainer, wanting to be responsive, merges them. Six months later the project is a Swiss army knife that's hard to maintain, hard to onboard new contributors to, and the original use case is buried…

It's even worse when you are telling the solo maintainer that this is where its going and they just keep accepting every minor contribution to make people happy and boost them if they can.

It's not a bad idea but it ends with just a huge mess of crap.

Re: Dumb ways for an open source project to die

#60

Post by tom_ »

ZeWaka wrote: post #27
Lerc wrote: post #21

Earlier quoted context omitted.

I was reading though thinking that only a few of these were dumb. I wondered if it was a reference to Dumb Ways to Die, but thought that was a bit obscure for a reference. Turns out, apparantly not. I think if I had have gone to all that work to write this list I would have given each one a dumbness score to communicate that circumstances are not equal.

> a bit obscure for a reference one of the most viral videos from 2012 is obscure?

Whatever age range you have to be in to remember the most viral videos from 2012, some measurable percentage of HN's readership probably aren't in it.
Post reply on HN