And if you work for big org it’s also often “this looks vaguely similar to one of our epics so let’s start using it and demand 24/7 support”
For example C was shared, C++ was evangelized. The difference is the effort put into convincing people to adopt your stuff.
Java for instance was mega evangelized, Sun thought it might reverse their fortunes.
Linux was initially “here you go, hope it works for you” but then it attracted many people who decided to create an ecosystem around it.
However, the amount of devs have grown exponentially, and the number of non-niche problems without a solution have dramatically decreased.
In my experience you can pretty much always bet on greed, money, and psychopathy to ruin anything that reaches beyond Dunbar's number.
It's sad when your playground gets overrun by drug lords (metaphorically speaking); I don't really have an answer to that. It's my central trauma.
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.
The io.js fork from node back in 2014 (?) 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.
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.
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?
The kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. Good luck to them.
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 treats the project and its users as their little empire, the situation is bound to get sad.
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 they can keep their empire. That seems fine; they didn’t want to go east, the fork going east means that those users who also want to go east can be served.
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 under complexity.
The antidote is a clear CONTRIBUTING.md that says "here's what this project IS and ISN'T" and being comfortable closing issues with "out of scope, but would make a great separate project."
Easier said than done when you're a solo maintainer and every closed issue feels like you're letting someone down.
AI has just made this so much worse.
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.
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.
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.
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.
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.
Like leftpad?
FTFY, e.g nvim-treesitter:
https://github.com/nvim-treesitter/nvim-treesitter/discussio...
https://m.youtube.com/watch?v=IJNR2EpS0jw
https://m.youtube.com/watch?v=eq-GYfRjxhM
https://m.youtube.com/watch?v=yhJJws3kgzY
Edit: Yes.
"The Melbourne Metro safety campaign this post is named after closes with “be safe around trains,” which is more actionable than anything I’ve got."
Joke aside, these do represent surface of attack.
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 users or develop your software alone, an alternative is to sell the software and support service to users and use the money to hire developers.
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).
so, just be safe about it, i guess.
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.
one of the most viral videos from 2012 is obscure?
If you are really motivated, leave instructions on how someone else can pick up were you left off even if it is just an email address others can reach out to.
This is not dead. Open source projects don't have to be developed out in the open.
This is missing the "someone claimed they wrote all the code from the original repository and is now doing everything they can so that the author will vanish or have their reputation destroyed so theirs won't." Tactics can include claiming authorship within the gated walls of Big Tech and using their power to oppress the author. It's actually them that's stealing work, not them. Other's can include gang stalking the author.