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

91–100 of 155 posts

Re: Dumb ways for an open source project to die

#91

Post by dullcrisp »

jonnyasmar wrote: post #55
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 proble…

Do you all really have your random public git repos accidentally being used in production by Facebook? No one’s ever made one of my one-commit git repos a key component of corporate infrastructure.

Or do you mean that the meaning of what it is to “publish” something has shifted?

Re: Dumb ways for an open source project to die

#92

Post by mickael-kerjean »

Brian_K_White wrote: post #46

I don't recognize any such thing as a "dead open source project". If one project is dead, what makes another one alive? Recent updates? It's working as intended and no updates needed or worth the effort. Even if "working as intended" only means it works on some old platform and no current one. Other users? Why do I or you or anyone care about that? Other users only matters for commercial software where you are sellin…

Tell that to CVEs

Re: Dumb ways for an open source project to die

#93

Post by Gigachad »

d1l wrote: post #81
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…

15 years ago GitHub was a strong signal for like-minded devs who were of the “let me code and slide pizza under the door” variety. The signal became less meaningful over time so people started optimizing for other things…stars, whatever. Brand. I think the venn diagram of front end marketing types and the explosion of js frameworks probably was the driver for this. Now with vibed out projects everywhere it’s a real t…

The signal of quality for me is the number of contributors and the age of the repo. If I see a repo that's several years old and has many contributes over that time it's very likely a reputable project with some value. If I see a 1 month old repo with one user who has dumped the whole thing and then done nothing since, it's likely vibeslop that will be abandoned in a month.

Re: Dumb ways for an open source project to die

#94

Post by Gigachad »

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.

Anything connected to the internet or integrated with 3rd party systems will have to be maintained regularly forever. Anything that is self contained will last forever.

Main reason I avoid buying anything that requires an app. Because one day that app won't be maintained anymore and it just wont work, bricking the hardware in the process.

Re: Dumb ways for an open source project to die

#95

Post by Gigachad »

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…

You also get people who dump a feature in a PR you don't particularly care about, then that submitter leaves and ages later people start reporting bugs or requests on the feature you didn't even want in the first place.

Re: Dumb ways for an open source project to die

#96

Post by yowzadave »

dullcrisp wrote: post #91
jonnyasmar wrote: post #55

Earlier quoted context omitted.

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 proble…

Do you all really have your random public git repos accidentally being used in production by Facebook? No one’s ever made one of my one-commit git repos a key component of corporate infrastructure. Or do you mean that the meaning of what it is to “publish” something has shifted?

Exactly, I’m confused why people are feeling obligated to put more effort than they have interest for these projects. If Facebook did start using my project in production, then that would of course be their dumb decision that they would be responsible to fix!

Re: Dumb ways for an open source project to die

#97

Post by Aurornis »

sokoloff wrote: post #9
Aurornis wrote: post #7

A lot of edge cases on this list. Among projects I've used it's almost always maintainers losing interest or vanishing. Forking is always suggested as a solution, but some projects treat forks as hostile attempts to steal their project. I've hit fork deadlock before where a maintainer didn't want to merge important requests, but also became exceedingly hostile to anyone who tried to fork the project. If a maintainer…

It seems not at all surprising that the “other side” of a fork would view it somewhat negatively. The person planning the fork presumably views the mainline project maintainers somewhat negatively in that moment as well. They can be as hostile as they want; that seems nearly irrelevant to the fork decision. If the mainline won’t take a patch or wants to go in a different direction, forking seems perfectly valid and t…

> The person planning the fork presumably views the mainline project maintainers somewhat negatively in that moment as well.

This isn’t necessary. Maybe not even common. Forks can start as a testing ground or an experimental feature fork and grow from there.

We see headlines about the angry forks, but usually it’s just friendly differences.

The problems arise when one person wants to control the project, deny contributions, but also gets angry when someone forks the project to implement those things. They put the open source license on the repo but didn’t expect other people to actually do open source things with it.

Re: Dumb ways for an open source project to die

#98

Post by zhxiaoliang »

I feel it's also partly due to the poisonous online culture today. Negativity always prevails, and the loudest voices are the ones that get heard. Showing appreciation has become old fashioned, and creators feel the pressure to “market” themselves or risk being silenced by online platforms or drawn into the noise. It’s simply exhausting.

Re: Dumb ways for an open source project to die

#99

Post by marcus_holmes »

tamimio wrote: post #64

Very good list, I have seen most in action. I would also add AI where some people just make their own internal tools rather than making it open source to everyone. > Apple is the classic example of an employer that simply doesn’t let most staff do outside open source I have been encountering this a lot recently, and I don’t know why. Last one a couple months ago, a company wanted to hire me for some work and while al…

I work on a ton of different stuff, and this clause comes up for every job. I get them to remove it, or I don't accept the job offer.

For me, this is a red/green flag on management. The clause is legal boilerplate, inserted because it's standard and they can. They don't actually care that much about anything you might build outside of work. If they won't (or can't) remove it then the organisation is inflexible and the people who are hiring me have no power within it. Or the people who are hiring me don't understand my point of view. This is a bad sign either way.

I have had one "win" with it; I worked for a company run by a trio of absolute arseholes. One of them called a meeting and tried to bully me into handing over one of my projects because of this clause. I explained that my contract didn't have that clause because they removed it before I signed it. He got angry. But couldn't actually do anything about it.

Re: Dumb ways for an open source project to die

#100

Post by skydhash »

jonnyasmar wrote: post #55
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 proble…

> 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.

Some tools I use, like msmtp[0] just publish tarballs and maybe have git repo browser. I strongly believe that github is a tarpit for opensource work. Especially when a new developer is brainwashed in behaving like they’re a business under contract.

[0] https://marlam.de/msmtp/download/

Post reply on HN