Hacker News Reader

Comment by bryanlarsen | Hacker News Reader

What should happen is that is that the BDFL (aka king) should appoint a successor if they cannot give a project the attention that it deserves. I've seen this happen successfully many times, and have never seen the "wrong" person chosen.

The problem is that this doesn't happen often enough. It's a very difficult thing to do, putting your baby up for adoption.

So what GitHub should do is a little bit of social engineering to encourage inactive maintainers to bless a fork. It's more than that, of course: you have to ask somebody if they're willing to step up. It's unlikely that one of the forks is comprehensive but there are likely people that would be willing to make their fork comprehensive rather than see the project abandoned.

Handing over the reigns to a committee does not work very well, in my experience. It's better than abandonment, but that's all you can say about it.

View on HN

The biggest problem I've come across on Github is actually getting in touch with the prior maintainer. If the user disables issues on the repo, doesn't list their email nor their github username doesn't match up with something like twitter it becomes impossible to get in touch with them.

There's been 3 repos I've attempted to take over that had no one working on them for +6 months and this was exactly what happened.

I've had the same problem and have an oddly related problem. I have a really good contributor to one of my projects. The only way I can get in touch with him is via github issues. There's nothing in his profile that'll let me get contact him, or even google him.

Shouldn't the user have their email address in their commit messages? That's how I've found their email address – clone the repo and do a `git log`

You don't have to log your commits with a real address... I use a user+github at gmail address, but others don't. It would be nice to see people list at least a twitter account and maybe a homepage. For really high profile people/projects, I can see the option to be more private about contacts outside github... but for the most part, don't get it.

If GitHub had an "adoption center" for unwanted projects, that would be a step forward. At least give it to a maintainer who's interested.

Maybe a maintainer can mark a repo as orphaned and others can bid to adopt it using their karma? Then the maintainer has a list of people to talk to about the future of the project... just helping make that transition easy would be nice.

A simple project setting that says "Advertise as orphan" would suffice. Then a banner would appear on the page saying "This project is looking for a maintainer!" and have something akin to an apply button where you might add a short comment about your interest.

With the "Login with GitHub" feature now available, this could even be a third-party service.

It might be an interesting satellite project. One that doesn't require maintainer consent; start with statistics and highlighting, mention which projects have changed their descriptions and readmes, show contributor lists.

(github network graphs would be helpful for this if their performance was remotely acceptable)

In git every commit contains the authors email.

Not necessarily. Every commit contains something that looks like an email address, but there's nothing guaranteeing that they used a real email address, let alone one they actually check.

I'd suggest that when merging a commit, checking that the email is actually valid by talking to the person concerned is probably a good idea, maybe even when they're submitting the commit through GitHub.

Agreed -- what is needed is a peaceful transition of power from one BDFL to the next (which we've seen with many projects) or (better) to a benevolent oligarchy. A democracy, on the other hand, is emphatically the wrong way to build software (or, frankly, anything) -- and for open source in particular it leads one down the ruinous path of open source governance.[1]

[1] http://smartos.org/2012/07/27/corporate-open-source-anti-pat...

The problem seems to be that projects just lapse, the owner's stop paying attention and the number of forks starts to pile up. Perhaps when the number of forks hits a certain point everyone that has a fork should receive an email asking if they'd be happy to maintain the project. People could then put themselves forwards and the original maintainer could then review the candidates and decide who should take over (or confirm that they want to maintain the project).

But what about popular projects... I could see that if there are > than X forks over Y time period with commits and pull requests to the main project without any accepted changes.

Look at twitter/bootstrap for example. Huge number of forks for that project.

On CPAN, you can be added as a co-maintainer if there is a long-standing bug with inactive maintenance, you've fixed it in a way that's eminently usable by the maintainer, and you can demonstrate long-term fruitless attempts to contact the maintainer.

In the Github context, since pull requests are obvious demonstrations of the first two criteria, it seems to me the most logical solution would be simply to move existing forks over to a new maintenance fork owned by a popular fork maintainer with an explicit governance mechanism. Then the original owner isn't interfered with, but the new forked community king can go ahead with centralized management of the overall project if the community agrees with that.

There's very little coordination between forks and URLs point directly at repos, so I'm not sure how this would work.

I'm suggesting that there should be more coordination between forks. I'm not sure what your URL point means - that the URL is a unique identifier for the project and that there's no way to forward people to the new "authoritative fork", I suppose, which is a good point.

Perhaps an explicit forward on a moribund project or something.... Hm. You're right, though. The CPAN thing works because there's a centrally managed list of unique identifiers that point to the analogue of URLs (which are stored under user's names, just like Github).

Good point.

What about an email saying something like

Looks like you haven't been very active on project <foo> lately, <bar>. Would you like to hand your baby over to <baz> or <quux> perhaps?

where baz and quux are people who have been ranked as being most active in the given repo.

EDIT: With a click here to hand over your repo to someone else (and lift that heavy burden off your shoulder), obviously.

There's no call to action. Someone (including myself) will open the email, realize there's no immediate call to action and be like, "Ya I'll get to that" and nothing will ever happen.

Also, without something like the proposed citizenship with karma points and such, there's no good way for an automated system to suggest someone to turn it over to .

Why it has to be automated? What's wrong with actually having some mailing list or other community forum and discussing it there would could be the consensus maintainer?

If it's not automated, it requires to much additional effort. It is worth to do for really big projects which can't be developed without community effort, but not for smaller ones which almost work and only require small fixes from time to time.

Also on such projects people don't know each other, and don't know how much everyone have contributed, so there's no way to have meaningful discussion and consensus.

How about a system that ranks the "popularity" and activity on all the forks, and simply lists/suggests these forks when a repository is considered inactive? The community will figure it out ("this fork is the suggested source"), and no action is required on behalf of the owner of the original repository.

Reply on news.ycombinator.com