Hacker News Reader

Often a project, a club, or even a company only hold because of one passionate individual. Once he is gone, it is the end. It is very hard to find someone with the same level of motivation. Projects stop being maintained, clubs cease activities, and companies get taken over for short term profit.

It is particularly apparent in schools. Students start something, then they graduate and do something else. Most of the times, no one takes over, at least not in a sustainable way.

It is not always the case, but it is the most common outcome. Simply, I think there are simply more people who want to start something than there are people who want to lead somebody else's project.

I don't know how the idea that people are replaceable got so popular. Yeah, I know why some people tried to make it so, but it's so blatantly false that I don't understand how those people were successful.

Anyway, nobody ever simply gets replaced. When you change the people, things change. Some times it's a disaster, other times it's an improvement, but the result is never exactly like the beginning.

There is an interesting "converse" to this observation for open-source projects, though. Namely: if a nontrivial abandoned project is still widely used, it probably represents a major career opportunity for anyone willing to take over maintenance.

This isn't purely hypothetical: it's the foundation of my own career.

To maintain something you will need a match between what type of person is needed and what type of person is available. To start something, any type (well, very simply put) of person will do, often the need emerges from what they initiate.

This may also explain the imbalance you see.

Having said that, I also think that just as often it _seems_ no one is available, until someone steps down and things do turn out allright. Of course this idea that a project will stop if the passionate individual stops is based on exactly the observation you describe! So that fuels the idea but you'll never know until you stop.

I maintain two slightly popular open source apps, and my experience is that there are a lot of people interested in using your product, but very few people interested in contributing to it.

I've had a few people offer help over the course of the years, but unfortunately they don't always have all the skills needed, so they can only help with a part of the project. When they do have the necessary skills, they don't have the time.

As I don't have the time to keep working on both projects for free, I'll probably abandon the lesser used one. I'd love to find a successor for the second project, but to be honest I don't have any idea how to go about finding that person.

(I don't want to post specifics of the projects because I'm trying not to link this account with my real world identity)

Have you considered adding your project to a site like https://www.codeshelter.co/ ?

I don't have experience with it, but it seems active and better than abandoning a project.

Good luck!

> I've had a few people offer help over the course of the years, but unfortunately they don't always have all the skills needed, so they can only help with a part of the project.

So whats wrong with allowing them to help with those parts?

Allowing people to help also takes time...there's a non-trivial management effort involved...one that's too frequently forgotten about in these discussions.

This is very true. Even when collaborating with very skilled engineers, it takes a lot of time and energy to respond to ideas, questions, and review PRs. It’s like a regular programming job to a certain degree, but you’re typically not paid for doing it.

Software can be shitty garbage in many ways. It can be shitty garbage by having lots of bugs, and it can be shitty garbage by having a maintainer which cares more about bottlenecking all changes than about the future of a project.

But everyone is free to make shitty software, so have at it.

Wow, calling people's software shitty because they care enough about it to want to vet contributions?

I don't know why you're being downvoted for a truly honest question.

The answer to this is that getting partial help sometimes costs more time than getting no help at all.

This seems like one of the potential tragedies of the "all volunteer" development model. Many of the factors that play into Brooks's Law apply just as much to volunteer efforts as they do to commercial efforts.

One of them is the cost of communication. My sense is that the overall cost of communication scales in a manner that's more in line with the number of active contributors than it does with the actual volume of communication that they produce. Even the actual time spent communicating may not do so, but the kinds of communication - getting to know new people and new teams, negotiating different and potentially conflicting needs, stuff like that - tend to be more tiring than the communication you get in a stable team of people who have been working together for a while.

But, if you can't make a living doing it, then you probably aren't prepared to contribute more than a very small amount of your time. A large group of people doing that might have an outrageous communication cost relative to its productive output. With the brunt of that being born by the maintainer.

I would imagine that, if we could figure out a better way to enable maintainers to support themselves and their families while also working on their project full time, things might work out better. More time spent programming means less need to negotiate with and review contributions from others, and the work getting done more quickly because it's being done by the person who knows the code best, and the job being both less tiring and less thankless, and possibly leads to higher quality (by virtue of being more coherently designed) software in the long run.

"I don't mean to let them die, I mean, to find like-minded individuals to which you can defer some or all of the work?"

I've seen lots of these calls for help fail.

And someone else points out: It's open source. Literally anyone can continue the work at any time. There's no need for the original creator to find someone else to continue it. Anyone can just do it.

Anyone can just do it.

They literally can't though. Only the owner or a maintainer has permission to merge PRs in to the main branch. Anyone can fork a repo, write a patch, and PR it, but that's where outside contributions stop. It still takes someone from the original team to accept a contribution. Forking a project and then maintaining that fork as a separate project is an option, but it's divisive one that a lot of the community will react badly to if they see it as a hostile takeover or if there's a change in goal (eg making a commercial product out of the abandoned project.)

There are endless examples of forks that pick up where some other project left off. They give it a new name, explain what's going on, and move on. If it's seen as hostile, that means the original project is still active and doesn't need this?

This has happened with some pretty big names, too. gcc did this, and so did Jenkins. Didn't node.js do this a few years ago, too?

This is a serious shortcoming in github's current UI. There's no easy discovery for which forks are active.

It would be useful if there was a checkbox "Actively Publicly Maintained" in forked repos that defaults to Off.

That way, on the forks page of a repo, if someone is offering an alternative, an "actively maintained" check mark (and perhaps a date) can be shown and it can bubble to the top of the "forks" list.

Even just finding out which forks have any changes compared to the main repo is difficult on GitHub.

There is a graph showing the fork activity. Also, the setting you are thinking if is probably “archive”.

A fork having activity doesn't imply it is a publicly maintained fork that people can rally around.

Many of forks are made for personal purposes, experiments, one offs to patch bugs, to keep an eye on a project, or other reasons.

I'm thinking of the opposite of "archive" -- a setting that means "I nominate myself to become the lead repo for the community to rally around should the community be interested.

On this repo, can you tell me which fork the community moved to for this dead project?

https://github.com/lightbody/browsermob-proxy/network/member...

All valid points. I do miss some sort of guidance every now and then on some repos. The most difficult bit starts when multiple forks have different features one wants to have in their own fork.

It would be awesome if there was a way on github to say "give me the upstream with this repo cherry pick, this repo cherry pick". But that might be pretty difficult to implement.

There's version control other that Git / GitHub / etc. It's even possible to forego version control and just release tarballs somewhere.

Ok, but you'd hope there's some form of access control that stops someone just overwriting the canonical source with their own version. That's the same as the maintainer having to accept changes.

If there isn't, and anyone can write straight to the source, then good luck to anyone using that package because it's probably not very safe.

Or you maintain your own version. My projects got booted of GitHub when I did; I don't maintain a site anymore; but there's several forked versions of them floating out there somewhere, presumably because someone's still using them.

There’s a community aspect to consider though. You and I could both decide to continue some open-source project. The community will (reasonably and maybe even “rightly”) look to the original maintainer for guidance on which 0, 1, or 2 forks they suggest to continue.

It's even worse with other patterns, e.g. when the original project is suffering from some bit rot, the maintainer is unresponsive for months, independent forks spring up to fix that rot and suddenly you get a bout of activity in the original project and then another lengthy period of silence.

Yep. I think its important for project maintainers to be clear about the maintenance status of a project. You don't have to maintain a project forever, but if its not maintained its good to be clear about that.

Eg: "This project works but will not be maintained. Github issues & PRs will be ignored. If you want changes, fork the project. If your fork is being actively maintained, let me know and I'll link to your fork from this readme."

This is truly frustrating, and happens in organizations as well. It is admirable when people actually make decisions.

Sure, one thing (it being OK to drop an already open source project) doesn't exclude the other (suggesting a fork if there happen to be any).

In my opinion, there's just a shortage of experienced engineers.

Everyone these days is chasing the latest Javascript framework hype and practicing the next big modern language, e.g. Rust or Go.

But most important infrastructure open source is written in C++ and to maintain a cross-platform library linked into hundreds of apps, you need years of practical working experience to accurately estimate the side effects down the line from a seemingly innocent patch.

There's few people who have that experience. Plus as the greybeards retire, more and more companies need to hire this kind of developer to keep their own stuff running. So the people who could do open source usually have a waiting list for future freelancing clients.

As greybeard, I see the golden age of FOSS like disco/hippie days, eventually the majority that was against the man ended up working at wall street like jobs during the 80's and early 90s.

Same will happen when everyone that actually made BSD and GNU happen is no longer around, it will be business as usual.

I think part of the worry of handing projects over stems from a couple of fairly high-profile events when projects were handed over to theoretically trust-worthy people who went rogue and used them as a platform for malware or spear phishing.

Suddenly, even just relinquishing control can be a bad thing for the community.

What's really required is to build a community large enough that the 0.1% of people who can run it are big enough to have a group in charge, set up a foundation etc etc. It's just like going from a monarchy to a democracy, hard, takes ages, fails a lot.

That won't work for most small projects though, so orgs like https://sfconservancy.org/ exist.

Not sure what other options like SFC exist, and the differences between them though.

At a minimum you'd want them to be in charge, and fire the current lead developer if they go rogue.

The thing is, if the new project maintainers go against the community, but the community really need to use it, the community will just fork out a new path and move on. If the project is really open source.

Nobody forks anymore. Almost nobody contributes anymore.

People have no idea that's it's mainly charity. And even then people demand, get angry, don't read any docs, etc, etc.

Bigtech sometimes helps by employing these guys. What is really needed is a service, which does the moderation and filtering. Kind of like oss communication management as a service. For example by github.

Something like the patreon thing for sure which also means community outreach and engagement.

It also means supporting other people and stepping up. It’s so few and far that’ll pay value for value.

I think that was always the case — the majority of people don't contribute meaningfully, and was quite demanding. I had an old open source project that got a few users, and eventually too many support requests for me to handle. Somebody stepped up and helped maintain things until I lost interest, but that was a very tiny fraction of the people involved. I was lucky there and (as far as I know) they never went rouge.

Outsourced moderation would probably end up something like Stack Overflow — useful things will be closed because non-subject-experts can't tell the difference between invalid questions and valid questions that look like invalid questions.

I don’t think that really happens, anymore.

Twenty years ago, they would have done that, but these days, someone would just write a replacement from scratch (quite possibly, proprietary), or everyone would abandon it, along with their own projects that depend on it.

Most open-source (and closed-source) APIs and SDKs are “Swiss Army knife” projects, with many functions that serve many purposes. Most API consumers use only a subset of the interface, so “rolling their own” is not that intimidating.

I think with all the security problems that we’re seeing, these days, we may be headed for some agency/consortium that validates dependencies (with all the myriad problems, therein).

We may be seeing more “semi-proprietary” stuff, soon.

Not necessarily a bad thing, as I think that anyone that makes money on software should probably pay for it.

I think we are straying from the point of FOSS once we talk about money. If I start a new open source project, it will be my gift to the world, and I expect to gain nothing from it financially. If Google make a billion bucks from my project then I'm sure some other dudes running a startup is using it too, and if my project helps them then I'm happy. If my help is not appreciated, lotsa luck gentlemen ;)

As I have made my point before, if all I want is money I would spend my time working a paying job. But money is not everything isn't it?

Preaching to the choir, here. Take a gander at my work.

But making things that other people depend on is an obligation; not just a vocation.

I liken writing an SDK/API/library to having children. Once they are there, they aren't really my "property" anymore, and I am under an obligation to maintain and support them, so I need to keep that in mind, when I publish them. I need to play the long game.

I've written a system that is used by thousands, around the world, and is the backbone infrastructure for a particular demographic. It is not hyperbole to say that lives depend on it. I worked on it for ten years, before transferring it.

The best thing that I ever did for that system was toss the keys to a new team, and walk away. Nowadays, I'm just the dorky old man that chips in his two cents' worth, from time to time.

I'm not particularly interested in getting into religious battles, which is fairly common in the [F]OSS community. I mostly code for the love of the craft. Delivering and supporting open-source projects helps me to have a purpose, but I also take my obligations quite seriously.

One of those obligations is to go to great lengths to deliver very high-quality software. I'm quite aware that it is not commercially feasible to write software that meets my personal Quality bar, so I give it away for free,

Also to refute your point here, I would say that there's not really that many project maintainers that just totally go rogue and kill the whole project. An event that was most similar to what I describe here is the Freenode boogaloo, and you can see that users started to move to Libera.Chat. If you advertise your product as community oriented and do stuff that your community despises then you basically have just shoot yourself in the foot.

TBH, I'm not exactly sure how that "refutes my point." I apologize for mentioning money. I think that may have raised some hackles.

I'm not sure if it's "become" rare or rarer. But in a way Github, npm, or maybe it was just ourselves in general... but we seem to have promoted the idea of "build it and they will come" to an unrealistic level.

While interested people will come, I think it is rare that a distant and complete stranger will suddenly appear and not only share your same interests but also with the same level of compromise. And given that some projects now seem to suffer sudden popularity growths as flavour of the month -or week-, it would also be rare that such a person or persons would appear before that happens and the pressure suddenly increases.

I think with the modern internet, and GitHub, it's much harder. It used to be reasonable to make a release every year or so, and basically not be in communication other than that. You could also assume all your dependencies would release updates every year. Now people expect replies to their GitHub issues within a few days, if you have CI you were probably using Travis and had to update everything, etc.

I believe that GitHub problem is that people not into software development are pushing those actually developing at a very low developer/user ratio, it always feels like a never ending task and people won't ever stop asking features as they got used to see Corp projects next to project garages in the same service?

To release way less often has been one of the best changes I've made and also dual licensing. If people will get me a hard time then pay for that part of the development.

It's actually very hard to find help on an open source project. People are fine with submitting the odd PR here and there or reporting issues, but actually RUNNING a project, in whole or in part, is a serious commitment that few people will find the energy to stick with.

> But, is it just me or has it become rarer for open source project maintainers to feel free to let projects go? I don't mean to let them die, I mean, to find like-minded individuals to which you can defer some or all of the work?

Burnouts like this happen, because it is not actually possible to keep working on side projects for 30 hours a week on top of actual 40 hours a week work.

Whoever would take it would face the exact same issue.

This is partially why over the last few years I've been moving away from using smaller packages in favor of rolling my own. Big things like frameworks are generally safe bets, they generally are able to build a community around them pretty easily. But smaller libraries are often not worth the long-term risk.

> But, is it just me or has it become rarer for open source project maintainers to feel free to let projects go? I don't mean to let them die, I mean, to find like-minded individuals to which you can defer some or all of the work?

There are few projects that actually get used for longer than a couple years at most, the churn (especially in JS projects) is massive. You'll always find people to work on Big Old Stuff that's used everywhere - think Linux kernel, Qt/KDE, Gnome, Firefox, Thunderbird, libc, gcc, LLVM, jQuery, ReactJS - but the small stuff that gets disrupted ehhh replaced by some shinier newer toy? That will eventually diminish and die off, when the original author either has all their needs met, burns out or no longer needs the project.

Additionally, all of the above projects have massive financial firepower and/or other institutional backing behind them that contributes either with direct man hours or financial grants.

Is this just a function of how long it takes to recreate ~80% of the functionality?

It doesn't matter if it takes half a decade to implement the last 20% of the feature set and iron out all of the bugs and corner cases, if you can bang out a prototype in a long weekend, someone is going to do that over and over. Meanwhile, if it takes nearly a year just to get something half-working, the existing open source codebase has to be pretty bad for you to not at least fork it.

> there is nothing wrong with putting out a call for someone to take over maintainership

Why is this necessary? If someone wants to start maintaining a project, all they need to do is fork it. For example, ZBar is now being maintained by a Linux kernel developer. His fork started getting updates and contributions and is now objectively better than the original project. Linux distributions have already accepted it as the master branch.

> But, is it just me or has it become rarer for open source project maintainers to feel free to let projects go?

Social media - and GitHub is definitely a social media tool - gives people an easy way to shout at you whenever they're unhappy, and gives them plenty of tools to get in your face while making it very hard for you to cut them out.

A temporary BDFL... Would that be called a TBD (temporary benevolent dictator)? :)

BDFN: benevolent dictator for now

when I started work on ts-loader I went with "caretaker" https://blog.johnnyreilly.com/2016/11/01/but-you-cant-die-i-...

Shouldn't it be BTD? Somehow that word order feels better.

With the concerns of the next maintiner going rogue, maybe the ambiguity in TBD is called for.

Benevolent Regent Lord

Benevolent Dictator Pro Tempore

Davidism took on Flask/Pallets really well, I think.

> But, is it just me or has it become rarer for open source project maintainers to feel free to let projects go?

I think it has always been rare. I generally avoid projects which are under a person's own github account because to me it is a massive red flag that they will kill the project by failing to maintain it and failing to hand it over at some point in time.

When you build a project the most important part is to eliminate dependency on yourself. If you are approving all commits, or doing most changes, you need to fix it, because it is a problem.

I don't really understand pedronauck's response. If he does not have time, he should tell people he does not have time and they should make PRs, is that not the point of open source projects?

There is nothing wrong with demanding that people help themselves, people are not entitled to your time, and unless you are not processing PRs then you are not the problem.

In an ideal world you're right. But most people don't create projects expecting -- or even wanting -- huge success.

1. Sometimes people create a project for themselves but use Github as a convenient place to store the code. I've done that before and found people filing issues against those projects.

2. Sometimes people create a project to scratch a personal itch and put it online in case it helps anyone else. Not in the sense of hoping people will use it but rather than in the "I bought 10 bottles of wine and only drank 9. Help yourselves to the last bottle" sense.

Maybe there should be (maybe there already is) a software license that should better explain the "wrote this for myself. You're free to use it but don't expect support".

3. Some people probably do hope that their project has some, maybe even just small, degree of success but they host in their own user profile because their Github profile is their CV and they're starting new projects in the hope of landing better jobs.

This 3rd group are a particular problem for open source. Not in the sense that they're doing anything wrong -- they're clearly not. But in the sense that you end up with a lot of NIH since the primary reason for a project existing is to boost the CV. So when the primary maintainer moves on, any future contributors will prefer to build their own solution rather for their own CV rather than taking over maintenance of the existing project.

---

It should also be noted that not all projects are large enough to warrant their own Github org. Take BurntSushi's stuff. I'd wager the percentage of HN developers who use BurntSushi's code is in the double figures. But there'd be no sense in every one of his projects being it's own org.

> Maybe there should be (maybe there already is) a software license that should better explain the "wrote this for myself. You're free to use it but don't expect support".

Put that in the readme?

Pragmatically I think you're right that developers should put that but it feels like such a hostile comment to make that I certainly wouldn't feel comfortable publishing it.

There's probably a better way of phrasing it than I had though -- a way that is less standoffish.