I often observe that people that started a small open source project seem to abandon it sooner or later. I’m guilty of this myself in numerous cases. Reasons there are many probably, from new obligations in life to shifts in interest and whatnot.
At some point somebody comes by with an issue, or a merge request even, but the maintainer does not take care of it. Usually this ends up in forks, often though forks undergo the same fate. Apart from the immediate forks-jungle, stuff like software stores or other things might be hardlinked to the original repo, which means places like these end up with dead originals and a number of forks with varying degree of being maintained as well.
To me its just a sad situation overall. And yet I cannot find the time or motivation to maintain some stuff, because circumstances just changed. And I also do not think one is obliged to do so, just because they where nice enough to share their code when the project mattered to them.
Is there a better way? Usually these are very nieche projects, and there is not a circle of regularly active developers that could share administration of a repo, but rather a quiet one-man-show with a short timespan of incredible activity. Some kind of sensible failover mechanism once the original maintainer vanishes would probably be cool. Or any other way that introduces some redundancy in keeping a repository alive. You know how package maintainers in Linux distributions open their package(s) for adoption by somebody else if they run out of capacity? I think that is nice.
I will publish a small project soon I think, but somewhere in the future I fear to leave one or the other person frustrated again when I have moved on to other things…
I don’t think that’s really any kind of flaw. Not every project needs to be actively maintained.
It’s OK to write something as a one-off because it’s useful to you. It’s OK to share that to other people with a license that allows them to use it for their own purposes without making a commitment to work on it forever. It’s OK if it’s never particularly useful to a general audience and only serves as a small convenience for other people who can follow the code and adapt it to their own purposes or make modifications for compatibility.
If 1% of products that are shared unmaintained save 1 other person some work and 0.001% serve as a jumping off point for someone down the line into a project that forms a community around it, that’s still a net positive, isn’t it? I’d try not to make promises I’ll actively maintain it if I won’t, and be descriptive enough to make it easy to find your project if you’re chasing the same problem and easy to read/adapt the code, but making it available, in and of itself, is a service.
The problem isn’t that FOSS projects are getting abandoned. The problem is the consumer mindset where FOSS projects are considered as the free (gratis) equivalent of proprietary software - a well packaged and eternally maintained ware that you just install and run. This is a convention that bigtech cultivated in order to get free labor and support.
The original free (libre) software philosophy was designed with sharing in mind. Somebody writes software to scratch an itch - i.e solve their own or someone else’s problem. And then they leave the source code for others to adapt and use. You found a software that you like, but is abandoned? No problem! Just take it, update it and use it. I have done this. Don’t know how to code? Ask someone else to do it for you - perhaps for a price.
Back in the early 90s someone told me, “source code gets lost, but binaries live forever.” It was true back then (because of the way people shared files by trading floppy disks) but I think today in the open source ecosystem, actually the opposite is true.
A project may not get packaged or released anymore, but as long as the source code is still available, new people can make use of that work and make derivative works with their own modifications.
I worry that too much of our collective community work is siloed in places like GitHub that one day may throw out old repositories while spring cleaning. I hope that we see the same level of effort put into source code preservation that organizations like the Internet Archive put into binary preservation.
The “binaries last forever” is still very much true in my field (industrial automation). For example, companies develop functions to speed up and simplify PLC development and “lock” the code to keep their competitors from copying it.
I was editing a PLC program on a government installation just today and ran into this. The government was never given the code (even though it rightly belongs to them) so I have to take it on faith that it’s bug-free. I rewrote it and left it unlocked.
There’s also an expectation that software is supposed to be updated. However, the software may be feature complete at a point of time; it’s goal has been achieved and there’s nothing more that author feels to add in the current feature set. Is the software abandoned now? Definitely not. Author may choose to push security patches but they are not obliged to.
I think problems that turn up with time are also things like dependencies moving on, people with a slightly different setup which unfortunately breaks the thing or at least surfaces bugs, or that the author doesn’t even use the software anymore because it was hardware specific and they have other hardware now etc… Yes they are not obliged to anything, that’s what I think too. I was more thinking in the direction of taking some precautionary measure that makes the project stay more useful (and maybe more maintained) when the original author has long abandoned it.
Some suggestions;
-
license it in GPL or another copyleft license so that future contributors will contribute back to the source and not just take what they want and leave. A lot of issues with open source projects not being maintained is because people will spin up an MIT or BSD license and then people, corporate employees, etc. just grab what they want and never contribute back.
-
document all of your code ad nauseum so whoever wants to take over can understand everything easily. That way minimizes NIH syndrome or feeling like it’s easier just to restart.
-
before you turn off the lights, leave a roadmap.
I like your second point, and already started polishing the thing more than I would have for just my own purposes. It’s a good way to make it easier for somebody to take it on in the future. And it’s also a measure that the original creator more likely has the will to implement while focusing on building the thing, i.e. before they moved on to other things. Also for my current project I try to keep it simple. It may not be the prettiest, most configurable or universal tool. But it has a short code and minimal dependencies. Thank you for your comment, that made me think about how traits like this can become very valuable for others.
Your first point I do anyways, and the third I’m not sure about yet. Maybe documenting such things as issues preserves them decently.
-
Hot take, but the main issue is - developing a program requires programming skill. Shocker, I know. But think about it, a ton of people may be interested in “taking on” a project, but without being a programmer, nothing can come out of it, unless somebody takes care about the program so much they’re willing to fund development.
Is there a solution? Maybe soon we’ll have AI programming assistants good enough that even a non-programmer can do something useful with source code. At least temporarily keep the project alive with minor updates until someone more experienced comes along.
You know what grinds my gears more however? Rewrites. Whenever a small foss projects announces a complete rewrite, I consider it done, as it’s virtually certain it will be abandoned and the rewrite will never be finished. Seen that soo many times, it’s insane why people attempt it in the first place. Actually insane if the same thing keeps happening over and over and yet you expect different results…
Recently I’ve seen that NewPipe is getting a rewrite. While I have more trust in these guys than in some other projects, it’s time to look into alternatives.
In my experience if you don’t have solid code coverage and modularity your rewrites are doomed.
Unless you can merge as you go with code coverage ensuring stability it becomes a quagmire. 10k+ LOC PRs are impossible to vet.
Jazzband is a pretty good take on the problem for Python projects. The approach could probably work elsewhere too
Ahhh that looks very interesting! It seems to commit on actuall maintaining the projects that make it in there, hence of course trying to keep the number small and only letting relevant high quality projects in. That’s of course more than gifting ownership of a project to the public for somebody to grab, but a rather nice concept nontheless!
