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

41–50 of 155 posts

Re: Dumb ways for an open source project to die

#41

Post by to11mtm »

foxglacier wrote: post #24
ndepoel wrote: post #4

Here's another: code was open sourced with every intention of becoming a thriving community-driven project, but in practice users only take from the code what they want for their own needs and never contribute back, or expect the maintainer to solve all of their integration issues for them. Eventually, the maintainer decides that they have better things to do than fixing other people's problems, and that there is mor…

It sounds like the maintainer you're describing was underhandedly helping their users with the silent expectation that they also contribute back to the project and got bitter when it didn't happen that way. Open source is altruistic, remember. You explicitly tell the world that you are happy for anyone to only take from the code what they want for their own needs and never contribute back. If you don't want to help u…

I think I know the pattern they are describing, and it's a semi-unfortunate one.

People make a fairly-complex open source thing. Due to the complexity for certain environments/cases, the author(s) have a commercial support option.

Consumers from bigorg use it, and wind up opening issues wanting free help for their niche use case, no they don't want to get a support contract, but this subset of the user base causes a lot of churn dealing with communication, politely closing such issues (after all, you want to just be polite about support options, not drive them away!)...

And sometimes, it becomes easier to just flip the license.

In the .NET ecosystem, it's come up frequently. There's the cases where I get it; PDF is hell (iTextSharp), Imaging is hell (ImageSharp), Auth is hell (IdentityServer).

But then there's the cases where I just shrug my shoulders (MediatR has plenty of alternatives) or get happy it gives me permission to gleefully get rid of a poorly used lib (AutoMapper).

Re: Dumb ways for an open source project to die

#42

Post by bartread »

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 with how long all of this was taking.

So a group of them forked off io.js from node, did the upgrade and a bunch of other improvements, and eventually all of that was folded back into core node, and everyone was happy with the final result.

But I think we could have found ourselves in a world where we'd all be using io.js rather than node had it turned out slightly differently.

Re: Dumb ways for an open source project to die

#43

Post by to11mtm »

ricardobeat wrote: post #40
usernametaken29 wrote: post #14

I remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions. Each individual artefact is tiny so forking it is really simple. Instead of building a massive library you mix and match for your use case. The platform itself can host test cases decoupled from the definition. With AI this sounds much more rea…

Your comment is easily misunderstood, my first thought was also “that’s NPM” - but the idea of providing tests and types without implementation is a pretty interesting one.

I mean in my head it is 'Plugin system', at least in the context of feature bloat.

Where it can get slightly hairy is that to do it well, you need to have a LOT of seams between layers.

> but the idea of providing tests and types without implementation is a pretty interesting one.

I feel like in my head, you need to have -some- baseline/example implementation; e.x. Akka/Pekko/Akka.NET have Plugin specs for Persistence but there's still a Memory-only implementation of Persistence as a reference/baseline; after all you need to make sure the spec is possible at all.

Re: Dumb ways for an open source project to die

#44

Post by jamesu »

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…

I've invested time working with a project like that and it's kind of heartbreaking to see it lose its way and become a total mess. It's tempting to fork and try and go back to its roots, but that has its own problems e.g. needing to invest a magnitude more time.

Re: Dumb ways for an open source project to die

#45

Post by esafak »

ChrisMarshallNY wrote: post #29

> Thesis orphan Phun Phact of the Day: Adobe Photoshop was sort of Tom Knoll's thesis orphan, but he didn't exactly abandon it. I have a bunch of repos that I have no intention of updating. I make it a point to always archive them; usually with a note in the README.

I wish more projects would archive themselves to send a clear signal.

Re: Dumb ways for an open source project to die

#46

Post by Brian_K_White »

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 selling copies or expertise or your resume or something tied to it.

If someone writes something and publishes it, and not a single other person ever uses it, and the author never adds another update, that is still not "dead". It's just software that exists.

It's some kind of focus on a weird goal. If your purpose in writing open source was for it to be popular, then buy advertising until you force it to happen.

Re: Dumb ways for an open source project to die

#47

Post by ferngodfather »

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…

So much this. Everyone has their own idea of that the project should do and it's hard to explain that whilst that implementation is great for their specific use case, it's pretty shit for everyone else.

AI has just made this so much worse.

Re: Dumb ways for an open source project to die

#48

Post by hibikir »

usernametaken29 wrote: post #14

I remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions. Each individual artefact is tiny so forking it is really simple. Instead of building a massive library you mix and match for your use case. The platform itself can host test cases decoupled from the definition. With AI this sounds much more rea…

There are a few usecases for this in some languages, where your functions might as well be class extensions. But you need a huge standard library with non-competitive types, or you end up with deep dependency stacks.

You also run into trouble if your language has side effects (ie, almost all of them). A leftPad that launches a fiber to mine cryptocurrency or sends an http call that fires nuclear missiles can still pass tests. It's hard to guarantee hygiene via tests alone.

Re: Dumb ways for an open source project to die

#49

Post by socketcluster »

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.

This. The core problem is that people assume that all software is necessarily unreliable.

The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole.

Not all technologies change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?

According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.

Re: Dumb ways for an open source project to die

#50

Post by OkayPhysicist »

usernametaken29 wrote: post #14

I remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions. Each individual artefact is tiny so forking it is really simple. Instead of building a massive library you mix and match for your use case. The platform itself can host test cases decoupled from the definition. With AI this sounds much more rea…

The missing piece there, that would be a real value-add over normal package repositories, is that functions can be small enough to simply be done. Function gets marked as such, it can no longer be updated, thus eliminating the risk of supply chain attacks and their ilk. IMO, most packages I actually use, with the exception of web frameworks, ought to fall into this category. My JSON parser should never update. My Knapsack-problem solver should never update.

These are problems that are hairy enough that I don't want to write my own solution, yet tractable enough that there ought to be a solution that never needs to be touched again. Maybe someone finds a better way of doing it, but the way they're currently doing it will never be wrong.

Post reply on HN