Abandoned open source projects | Hacker News Reader

Abandoned open source projects

jeffkreeftmeijer.com

102 pointsjkreeftmeijer33 comments

This would be a great feature. I have some projects floating around in various places that I haven't worked on in years, some of them very stupid looking back at them, and all of them not incredibly high in code-quality.

I still get support requests or requests for advice once in a while from people trying to use them, or thinking of hacking on them -- and these aren't even close to being popular projects.

I'm doing most of my open development on github these days, and this would mesh extremely well with the way that git hub, and more generally DVCS works.

Another possible nicety would be the ability to mark a repo as the "canonical" repo for a project. Right now that kinda happens with forks on github, but if a project is abandoned, and another person picks up maintenance on it, it would be nice to be able to say "this isn't the current repo anymore, look here instead" in a manner that isn't just putting a notice somewhere.

I think the new organizations feature of Github is an excellent way to address the need for a "canonical" repository. The fact that you can define an org for each open source project or group, and then add other users as admins mitigates the problems if the project changes hands, or gains a new primary maintainer. Just add the new "owner" as an admin for the group/repo, and nobody needs to be the wiser.

Yeah, but adding a whole organization for each open source repo? I have tons of small gems/libraries that solve one specific problem, and all enjoy their share of users/

I don't want to setup a bunch of organizations just because they might change owners at some point in the future.

We happy (and often!) re-root repos to show point to the canonical one in the case that projects get abandoned and picked up by someone else.

'Another possible nicety would be the ability to mark a repo as the "canonical" repo for a project'

"When you lose interest in a program, your last duty to it is to hand it off to a competent successor." (1)

I think something like this is the ideal solution, and - as kaens says above - I think if features are to be added then it would be great if they supported this process rather than just marking a project as abandoned.

(1) Eric Raymond, The Cathedral and the Bazaar, http://catb.org/~esr/writings/cathedral-bazaar/cathedral-baz...

Thanks for your suggestion, I always love reading detailed descriptions of what people would like from GitHub. However, now I've got a bit of a question for you...

My opinion is that every extra field I add to a page means I've personally failed. It's so easy to correlate databases to HTML that people often go feature-crazy adding fields to solve their problems and you end up with a product like JIRA.

However, as a designer I'm directly opposed to this idea. Every field I add to a web application torments me. I think about it constantly and scheme for hours trying to come up with any alternative to adding another field. I've been known to dream about "simply adding another field" for weeks. I need to make sure that this field is really going to positively impact my users. That it's more important than any other field already on the page.

So, would this inactive/status flag provide a significant benefit over editing the name/description/readme? I guess that's the question I'd like you guys to think about.

could something like this be done automatically? No commits in X months leads to auto-abandoned + fires off email to owner asking them to commit something to unabandon it if they want.

It's hard to say what active means. For example http://github.com/technoweenie/acts_as_versioned/commits/mas... hadn't had any commits in more than a year until today, but now it's up-to-date with rails 3.

The (current) last update of TeX is from March 2008. The idea is that it is stable, not abandoned.

You sure? I thought work was shifting to ǐTéX (ring!).

That's partly because Knuth's TeX is more the core of a piece of software than the software itself; actual distributions of TeX get much more frequent maintenance, and would bitrot without it. For example, the last commit to texlive (the TeX distribution most Linux users use) was 20 minutes ago: http://www.tug.org/svn/texlive/trunk/

Another aspect of this is whether the project is used by anyone. If a project like wget loses the maintainer, it's a big deal and we should shout on street corners about it until someone steps up. If a project is simply a piece of code that is of no use to anyone, even the original author, then we should at least rank it lowest. So maybe for the former it makes sense to add the extra field so that people can be notified instantly and someone could step up. Then again, IIRC wget did lose its mainrainer recently and someone stepped up very quickly since the project has other communication channels.

While I do like the idea, and it could certainly be nice to have as a user... I've got to vote against it. Abandonware can be pretty easily detected once you look at the page (name/description/readme/last update(!)), this would just put the "abandoned" label a layer higher.

I haven't looked through the GitHub API, but is there a way to pull the description? I see "abandoned" or something similar in there more frequently than anywhere else; a browser plugin could fetch that data and display the tag moderately accurately. Or color based on last activity, etc. and that way you don't have to add a field.

edit: on second / third thought, maybe that's a possible solution: show the last-updated date when multiple repos are listed. I know I'd find that useful. What defines an "update" is debatable... commits? Issues? Wiki? All of the above? Something else?

From a user's perspective, I find that the date of the last commit as well as the number of open issues are tell tale signs of the the project's state.

> So, would this inactive/status flag provide a significant benefit over editing the name/description/readme?

You can always cram more data into another field, but now you've lost easy access to valuable metadata--this would be a hack, rather than a solution. Proposing for users to use a hack rather than a clean, semantically different, UI element is not good on your part as a designer.

A "Status" field benefits users as repository pages can have a prominent notification of the current status. You can also use it as a flag for searches to avoid having to wade through various abandoned projects before finding one that is being maintained.

And for the GitHub developers, it will provide a valuable statistic. Now they can track the progress and usage of repositories without potentially using assumptions like "Hmm, this repo has not be committed to for X days--could be abandoned?" or having to parse through the description/readme for keywords like "abandoned" or "no longer maintained", etc.

So yes, I would say that this simple metadata field would significantly benefit the users and developers.

interesting idea, though in keeping away from feature bloat, wouldn't it be much much easier, and just as effective to put that information in the read me?

I realize the you said they don't want to but the info there, but why? If you really wanted to abandon the project why not just close the repo, which would shift all your traffic to another fork?

If github implemented this feature, I wouldn't be upset, but it seems very single purpose. Maybe a status flag, so the author can not just say "abandoned", but "up to date", or "active" though again, all of that can be seen through the commit history.

Just my 2 cents.

I agree that while this is a good idea, Github probably has bigger fish to fry and that at this point it should do fine to put the notice at the top of the README.

Perhaps someone can add the feature to the open-source Gitorious.

I don't think it's a good idea to make this dependent on github. The README or VERSION file could contain a note about the project status/quality: "version 1.2 -- abandoned". Simply creating an empty file named ABANDONED would work too for people who don't use github.

Indeed. What would be a nice addition to github is a way to mark another repository as the canonical one. I've been lucky enough to have a couple of my old projects taken over by new maintainers, and it takes a while for people to realize it.

I think that Github will re-root a repository if you ask them.

What if the user created a file named ABANDONED.rdoc and then Github displayed it before the README.rdoc file. It could even have a different color or something to make it stand out. That way Github doesn't have to add a new field to a form and the idea still works even off-line.

I'm generally not so sensitive about this but that article is annoying to read for me because of the font you've used (or the effects you've applied to it).

Good idea for abandoned projects however.

Out of curiosity, what are you reading it on? It looked perfectly normal to me (Windows + Firefox), but maybe it was due to some font issue on my side and substituting something readable.

Here's a screenshot: http://imgur.com/vdkMS.png

I've found this bookmarklet: http://lab.arc90.com/experiments/readability/ cures all my woes.

And if for some reason you can't run readability or prefer just linking directly to the extracted text, you can use my reader (based off of readability):

http://toadjaw.com/article?url=http%3A%2F%2Fjeffkreeftmeijer...

If you are on a mobile phone, you can view a mobile version of HN that also provides a link to my reader here: http://toadjaw.com/hn

What browser/OS are you using? Can you send me a screenshot of the problem? That'd make it easier to fix it. :)

I'm ashamed I didn't put this in my original post!

I can't recreate it on my machine at home although they both run the Debian testing branch and use Iceweasel. I'll let you know tomorrow but it's probably PEBKAC.

Okey, like I said yesterday it was my fault. Apologies. I have unchecked the box "Allow pages to choose their own fonts, instead of my selections above".

This is the first time it bites me in the ass though! It produces a shadow and lighting effect on the letters which is really distracting: http://imgur.com/qYkeh.png

Yes, the ability for the user to set the repository status to "abandoned" would be great.

I don't like the other idea about automatically setting the repository status to abandoned if it hasn't been updated for a while, because it's not necessary that project has been abandoned, because there were no code / repository updates recently.

I think it's a fantastic idea. I've oftentimes looked at the last commit date on a project and thought "Okay, is this abandoned, or has the owner just not pushed in a while?"

Github might also offer the ability to indicate the new canonical repository, for the case where the original dev has stopped working on the project but other folks have picked it up.

That problem will not go away, instead you'll have a new one: "Okay, is this abandoned and did the owner forget to mark it as such?"

I don't think this is necessary. The solution is to go to your project's mailing list, irc room, ask your twitter followers, or whatever, and ask for a new maintainer. Even messaging the users who actively report issues can be a good idea.

Once you have a new maintainer, announce it, open a support request in http://support.github.com asking them to re-root the network to the new maintainer's fork, and then change the description of your repo (a one click change) to something like "this is no longer maintainer, check http://github.com/otheruser/repo

Yes, it takes a while, but then when you solve it, you give the community a new maintainer. So I think it's a better solution than just marking it as abandoned :)

If anything its a level of convenience that I would definitely support.

Nothing is more frustrating than working with a piece of code (in my case usually a Django app), get giddy about using it and then realize that it hasn't been maintained in over a year and is littered with bugs you need to fix.

I actually think some sort of "no commits after X amount of time" warning / flag would work just as well. In fact, it might actually encourage people to maintain more projects if only to prevent the warning from popping up. Heck you could even turn it into a game...

Reply on news.ycombinator.com