Slashdot Mirror
Unmaintained Free Software Projects
DAldredge sent us linkage to the unmaintained free software project list (if you can't figure this one out based on the name, seek help quickly). A very good idea that I'm pleased to see implemented. There's a lot of orphaned software out there... some of it because it's pretty useless, but others just because people move on. Hopefully a site like this can help us breath life back into the good ones.
Here's where software projects go when they die...
;)
Most of these don't look too impressive, which is good, because I'd hope the decent software projects could find maintainers. (i.e. Everybody loves Mozilla, DOSEmu 1.0 is finally out now, and Wine got some more developers, thanks to Corel...)
Also, all the games are rogue or nethack based; please add Angband-Tk for Unix to that list, 'cause I want it!
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
- Code reuse is good. Rather than reinventing the wheel, it's beneficial to at least look at other's wheel-like designs.
- People will work on a project if it scratches an itch that they have. And just because the original author is no longer there to scratch the itch doesn't mean others don't want it scratched.
Just my $0.02--
The project is dead in the water! How can any new development harm it further?
if an inept project manager refuses to step down as the official leader of the project, if and when a more suitable project manager comes along.
I fail to see how this can be a problem for an open source project. If a better project manager comes along, nothing stops him from leading development (it's not like he doesn't have access to the source code or anything). If he truly is better, and the other manager truly is inept, guess how long people are going to continue working with the inept guy?
Let me see if I understand your position correctly. Because there's the possibility that the people reviving a dead project might not maintain it as well as it could be maintained, it's better for the project to leave it unmaintained. Where's the benefit in that! Even if the new maintainer is inept, at least the project gets some exposure, making it more likely to be noticed and adopted by competent people.
A project can die for many reasons, and it's odds of being picked up by someone else have less to do with how good of a project it is than with how much exposure it got. If the original team were not "glory hunters", the project may simply have escaped notice by many people. Especially in early phases, good coders don't spend much time on marketting, and other good coders aren't attracted by the smell of good code alone. They need to know the project exists before they can get excited about it.
The fact that some projects aren't worth picking up and some people aren't going to be good maintainers is a pretty silly reason to call this a bad idea. Unless you can confidently state both of those some's should be all's, your arguments are simply invalid.
--
"Convictions are more dangerous enemies of truth than lies."
I haven't seen much significant life in the netatalk code, apart from the asun patches (and when was the last one of those? :( )
Your Working Boy,
Two projects that died that I wish would be revived:
FreeDCE
tn3270
Finkployd
Who decides when a package is "unmaintained" or "orphaned?"
For example, in January 1998 I converted Columbia MM (the best mailer I have ever used) to an autoconf framework for improved portability. I wrote to the MM maintainers and asked for permission to release my modified source, but was told only that they would be happy to incorporate my patches. I submitted my patches, but no new release has been issued.
I do not mean to denigrate the maintainers. It is extremely difficult to hold down a full-time job and maintain an open-source project on your personal time. I hold no animosity for anyone who cannot give 100% to both jobs.
But it still leaves me in a quandary. The official Columbia MM maintainers are still alive, are reachable, are responsive, but they don't seem to do anything. I would love to release my source, but cannot.
If anything, this has persuaded me, more than anything else, about the fundamental importance of the the right to fork that the GPL/BSD licenses guarantee.
Go here for UFO - Unmaintained Free software and Open source projects. It's hosted by Bernhard Rosenkraenzer of Red Hat, who is also a contributor to the KDE project, which is the reason why /. ignores UFO (yes I'm joking).
--
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
The site for unmaintained Free Software Projects becomes unmaintained...
I wonder how many of these lists there are out there that are unmaintained themselves
Because I'm sure one or two of them have been subsumed into other projects along the way; they have been obviated by newer, more integrated projects.
Besides which, programmers don't get that "my baby" feeling from solely developing code. What _really_ makes us buzz is writing from scratch.
Still, there might be one or two projects still in there that aren't being redeveloped or implemented in other projects. And these may benefit from looking at how old they are, and whether or nor better technology (compilers, window managers etc) exists so these projects can be reimplemented with a more modern approach.
Strong data typing is for those with weak minds.
Strong data typing is for those with weak minds.
Shine on, you crazy diamond.
They're very similar indeed, but not exactly the same.
unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO (which has moved on to ufo.bero.org) wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are welcome...
This message is provided under the terms outlined at http://www.bero.org/terms.html
I can see that this page is going to be attract
free software wannabees, who see the opportunity to take responsibility for an already partially complete codebase in order to try to get kudos as the project manager. In reality though, this is likely to be bad for the project. I doubt that these newcomers will see the project as little more than an ego boost and a nice addition to their curriculum vitae, and many of these new 'project managers' will lack the ability or dedication to put the project back on track.
I agree that this is a potential problem - At ufo.bero.org, I'm trying to solve it by requiring that a new maintainer sends in a couple of patches before taking it over officially.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Such information can be useful for more than just people searching for projects to work on.
For example, someone researching the abilities of various software-licensing paradigms to quickly recognize and cut losses on failing (e.g. not useful enough) projects might find the information on such a site quite useful.
The upshot is while some might judge projects listed on such a site to be "failures", careful examination of the goals of such projects, and the costs of their failing (the costs to end users), compared to the opportunities to move to newer projects that might "subsume" them, could paint a picture of Open Source as being quite a successful way to develop and deploy software (which I happen to think it is anyway, but welcome any and all opportunities for objective analysis to be brought to bear on the subject -- which requires the sort of data posted on this site).
Practice random senselessness and act kind of beautiful.
So what's left? Not much I guess...
Wow, maintaining a list of unmaintained things in hopes that someone else will maintain them. I wonder if the author will maintain the list when the unmaintained projects are maintained again. MAINTAINENCE, I JUST BLEW A FUSE IN MY BRAIN!
Eh...
Old doesn't mean bad.....
By maintaining an existing project you don't have to reinvent the wheel. As for potential: the new maintainers might take the project on an entirely different road than the original one.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
It would be far better if people concentrated on creating new, innovative, software rather than simply maintaining age-old software. The only major benefit of a service like this is that the authors can have the satisfaction of seeing others work on their projects when they no longer want to. Nonetheless, I see little potential for the projects that will come out of this.
ByteMyCode.com: A Web 2.0 code sharing community.
I think that a parallel can be drawn between free software projects and the natural selection process which affects biological organisms - those projects which are redundant or poorly conceived (for example, the Java based word processor on the unmaintained projects page) will receive a lack of interest from the community, causing the developer(s) to lose interest and give up. Hence, the project dies by natural selection. On the other hand, good projects will have a natural vibrancy to them and should the main developers begin to lose interest, other developers will come forward to continue the development effort. The projects which are unmaintained are generally projects which have died for a good reason. Please let sleeping dogs lie.
It's not the same, though in the long run merging them will probably make sense.
They're very similar, but not exactly the same.
unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are VERY welcome...
This message is provided under the terms outlined at http://www.bero.org/terms.html
Try this: http://whatweneed.de/.
Usually this is due to the original author no longer having access to working hardware, or a platform that the hardware will work in.
Last year I tried to investigate why my sound card's Midi port wouldn't work with the drivers in the kernel. My sound card was on a weird daughterboard and not easy to remove without a hacksaw. Once I finally pulled the thing out, I dicovered that the main chips model number was later than any of those listed in the driver.
An email to the Linux Kernel mailing list received one reply, from Alan Cox, stating that no-one was now maintaining that code. In the end I amended the code myself after reverse engineering a DOS device driver. It didn't help that no specs for this particular chip were available.
Simillary the UMSDOS filesystem was broken in the 2.1.x kernel code for over 50 revisions, as the addition of dentries broke it big style. Once someone else took over the code things started to work, but it wasn't really reliable until very recently.
They should have called the site DeadMeat!
Does anyone know what happend to crackdot's game Golgatha (sp?)
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
The people who claim that no one will maintain old projects is simply wrong. For instance, I've been looking for the author of TkWine, a TCL utility that helps you update and maintain a WINE installation. Why? This is a utility I find useful, and it is nearly fully functional,and I'd hate to have to start from the beginning to get to where he/she has it now. The point is to get a system set up with the least amount of pain possible, and this is a useful tool to do it with. If I had to go and write the software from scratch, it would be just as easy to do the wine installation by hand.
As it stands though, TkWine has fallen into a state of disrepair. There is no one to contribute the bug fixes I've made to. So I fix them on my system and no one else gets to benefit from my debugging efforts.
If we, as a community, are going to simply let projects die when the original author moves on, then we might as well use closed source solutions. M$,et.al., put end user in this situation. They basically say, "We've moved on, so you're stuck with what you have, the way it is."
Note: If anyone knows how to contact the author of TkWine, can you tell him drop a line to echristley@hotmail.com so that I can ask him for permission to put the package on this sight?
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
I take no credit for this, I just feel it's appropriate. If the owner is reading, feel free to take all credit for it.
"I'd like to announce the adopt-a-coder program. After many long hours debugging why their program segfaults when given an input of 64910 characters long, but only if it doesn't contain the letter a and it's an even-numbered day, some programmers understandably... lose it.
You see, this is where the adopt-a-program comes in... after these poor souls go mad, somebody else needs to work on the code... and then they go mad, and so on. Eventually the program will be put into a usable state, but there's an excess number of insane programmers out there.
Here's what I suggest: Adopt-a-coder. For $10 per day, you can help feed an insane coder. All you need is a 12 pack of cola and cold pizza and/or ramen noodles. Provide him/her with a dedicated DSL liine, and rehabilitate him. It's a hard job, but it's also rewarding. You see, most people don't know that programming has little to do with computers, and more to do with large quantities of caffeine and memory loss. Unfortunately, the fallout from this is very serious.
PLEASE, help an insane coder. It's the least you can do."