Slashdot Mirror
Adopt-a-Free-Software-Project Program Launched
bero-rh writes: "We have just launched the UFO (Unmaintained Free software Open source) project -- an attempt to fix one of the very few problems with open source: People who used to maintain a package and can't do it anymore can leave it to the project where at least basic maintenance work is done. We'll also try to find a new real maintainer for the packages."
Looking for developers - take a look...
--
--
wxPython is great, but it is cross-platform and therefore may not have the ability to draw to the root window and do other X-specific things.
If multiple coders are all trying to actively maintain a project and can't work out their differences, then fork! Any open source license allows that. Either the duplication of effort will be recognized as wasteful and the code will merge, or one will wither on the vine, or we'll wind up with two different useful projects.
/||\
That's what Open Source is for.
__
(oO)
Hand me that airplane glue and I'll tell you another story.
Yes, i'm aware of WxPython, but haven't tried it yet. It may well do what i want, too. Unfortunately, work and life have interfered with fun coding projects. :(
/||\
__
(oO)
Hand me that airplane glue and I'll tell you another story.
I'd do the windows as borderless windows with a transparent mask over root, and a little X tweaking to keep the window manager from restacking them. This is how xfishtank and other things work. Moving them around should be no more computationally expensive than grabbing any window and moving it around the screen. If drawing on the root window sucks down the entire CPU, then the design needs some serious examination. I expect to be able to run lots of animations simultaneously without a significant performance hit on a modern desktop PC. If that's a problem, then it is my design that is flawed, not X.
/||\
__
(oO)
Hand me that airplane glue and I'll tell you another story.
Classic fuds from the mouths of the proprietary vendors, echoed by the suits. There is no accountability with proprietary software either. Read the EULA -- it explicitly says so. And it seems that proprietary software is orphaned as frequently as free software ( in fact even old versions of proprietary packages are usually unmaintained -- you need to periodically buy upgrades ). The difference of course is that if you're using free software, your replacement package is free, while with proprietary software, you have to fork out each time. Also, the fact that the code is available means that the author doesn't have anything to hide, and anyone can fix the bugs. As long as there's a lot of interest in the package you're using, it will stay maintained by someone.
Let us know if you do find such a business model.
I'm not the one who has to find that model, since I am not the one claiming that all existing developers can make money writing Open Source.
A Government Is a Body of People, Usually Notably Ungoverned
Errk! Does no one get it yet? I want to make an honest living as an Open Source developer. I don't want to be support tech or man the call center or have my stuff be a loss leader for closed source.
But I won't beg either. I don't need your charity so I won't accept it. Instead, give it to those who really do need it.
A Government Is a Body of People, Usually Notably Ungoverned
There is no more or less accountability with the "new" maintainer than with the old one. i.e. probably still not enough to convince your employer (if you're downloading for free). With Open Source, accountability is sold seperately -- by companies like RedHat, Corel, Caldera, etc. If you are purchasing a box from such a vendor, you have at least as much accountability as you do from MS, etc.
========
<sig>Guvf vf abg n frperg zrffntr
"I'm not the one who has to find that model, since I am not the one claiming that all existing developers can make money writing Open Source."
I don't think anybody is making such a claim. Some open source developers make money because the company they work for release the code they wrote. I don't think anybody has claimed ALL existing OS coders can make money.
Personally I don't think this is some great evil. If you feel like writing code great. If you feel like giving away code great. Nobody is forcing anybody to do anyting. I think there will always be steady stream of coders who are willing to contribute something in their spare time.
War is necrophilia.
It can't handle cookies or SSL either. (well, cookies can done with a hack , but it's a pain. it'd be much nicer if you could just point it at your netscape cookies file)
--
Initial development and maintenance are two very different phases of a software project. Many programmers temprementally suited for one are not at all happy doing the other. Perhaps this will end up as a clearinghouse where projects are routinely handed off from developers to maintainers.
And the brethren went away edified.
I haven't tried it myself yet (mostly due to laziness, FreeBSD 4.0, new gcc, etc), but I've looked at the documentation and it looks very promising.
I didn't see an option to volunteer testing the software. Should they just leave that up to the users?
:)
IMOP, at the very least there should be someone to handle the bug reports and try to recreate the situation in the bug report, then pass the results to the programmer(s).
I did notice that there was a choice for documentation, so thats good news.
--
--
I'd agree that #3 is the most important one...
;) )
;) ;))
Also you forgot
#4: The program does everything its author needed it to do, so there's no reason for him to make any
more changes.
#4 is quite common, as well. (Why add a simple user interface if find . -name "*.c" |xargs perl -pi -e "s,mayn,main,g" works for me?
If I had infinite amounts of money, I'd probably help with the project you suggested, but I'm a programmer, not a millionaire, so I have to try solving things in ways I actually CAN.
Utopia for me would be if I could work on various OSS projects like GIMP, GNOME, sawmill, VIM and my own projects, and make a decent salary
Much what I'm doing...
If you're good, send your resume to Red Hat.
If you aren't, try one of the other distributors...
This message is provided under the terms outlined at http://www.bero.org/terms.html
For interim maintainers, I'm planning to use a very simple algorithm - if you've already had a look at the "join" and "add" pages, you'll see we're asking a number of questions - they'll be used to check who can take care of a particular program.
For the future maintainers, see the FAQ.
If someone notices later that he doesn't want to take the package after all, he can just drop it back to UFO - we'll always have some people to look after them.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Actually it doesn't tell anything about the quality of open source projects, or even about the UFO project itself.
What did you expect? Every project has to start somewhere, and (of course) I didn't send a piece of SPAM mail around the world asking people to drop their packages off.
In fact, slashdot was the initial announcement of the project.
We're at 7 packages now, I'm expecting to see more when we actually start doing something about the packages in addition to providing a "trading place".
This message is provided under the terms outlined at http://www.bero.org/terms.html
Some projects get abandoned for good reasons aside from lack of time.
Those aren't the ones we're interested in.
Check the FAQ - basically any *still interesting* package qualifies.
If a maintainer drops a package for a good reason, he won't drop it off at UFO, and we don't "steal" packages without the maintainer's consent, unless there's no way to contact the maintainer.
This message is provided under the terms outlined at http://www.bero.org/terms.html
We noticed something like the project was needed when I noticed just how many packages from Red Hat Linux 6.0 are still the same base version in 6.2... ;) ) - but improvement is what open source is all about: If you have a better name, let us know.
The priority was getting up something that works, not picking the ideal name. I'll admit I'm not very creative about names any day (check the scripts from the Free Film Project for another fine example of me not being able to pick names
I'd rather have a project without a fancy name up and running than just delaying it forever.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I'm on the outside (closed, custom work in Windoze-land) looking in, but it seems to me that what you ask is already happening, just not quite quickly enough for your tastes.
For example, how many *more* open source coders can RedHat employ this year than last? And as the customer base grows, how many more in-house coders will be working on open source stuff, providing mods back to the community? After all, IBM's now-robust commitment to Linux and open source began with serving their own needs on Apache and AIX compatibility, etc.
Just remember, 90% of us, including me, and apparently you, make our living off of building software that never goes retail. But is that because every business that comes along invents its own way of doing things, and thus has unique software needs? No, it's because either the software tool you and I are building:
A) never got built,
B) got built for a one-off implementation,
C) got poorly built for sale, or
D) got well built for too high a sale price.
Open source has already encroached on commonly-needed software in C and D, and is quickly consuming more of that space. Standardization will bring more of the stuff in B into the realm of common enough to benefit from open source, and A means nobody was going to pay for it, open source or not.
Because software is so desperately needed, the valuable stuff will get built. Because the talent pool is finite, some cool, but not valuable stuff will languish. Neither open nor closed source changes this, but open source at least offers some hope that we won't all spend careers building the same thing over and over -- witness the Y2K bug. How many times was that baby fixed? gcc or somesuch sits on almost as many computers as had Y2K-buggy software, but it only takes one coder to patch a bug in it.
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
Will the old/new maintainers have the right to close the source at any point?
Why would they want to do that? The program obviously will need to be maintained, and if they close the source, it may end up in a situation similar to the one that landed it in the UFO project in the first place...with the exception that since the source is closed, nobody can do anything about it.
=================================
I pledge allegiance to the flag...
of the Corporate States of America...
I'm actually working on a project to write a replacement for xfishtank, as well as xroach and a couple of other classics, and some ideas of my own (it all started when i went in to try to fix something in xfishtank, and realized i was dealing with code that dates back to X10!). My goal is to develop a generic "sprite" animation mechanism for the X root window, which allows sprites to interact with each other and be aware of other windows on the desktop, and separates the animation images and rules from the display mechanism.
/||\
Right now, it's still going through a lot of basic setup and experimenting, but i hope to have source up as soon as i can get a few evenings to hack at it again! The project is at https://sourceforge.net/project/?group_id=2502, but there isn't really anything there yet.
At this point, it is looking like the code will be written mostly in Python, with a small C library for the actual root-window drawing routines and drawing-related events (Xlib, ugh. But i can't seem to do what i want with PyGTK). To create a new animation type, you just inherit from a generic xsprite, and extend with your own movement rules, interaction rules, and animations.
Here are some of the animations i have planned:
* fish, a la fishtank
* roaches - they try to hide under windows, and scurry when you move them.
* tanks - like Atari "Combat" tanks, they drive around the screen trying to shoot each other
* spacewar - like the tanks, only with gravity
* flames - burning along the tops of windows
Feel free to jump in and help, once i have at least a minimal working system!
__
(oO)
Hand me that airplane glue and I'll tell you another story.
However, I would hope the project will not just focus on existing code that has been abandoned, but will also deal with the following issues:
They could help such program to create a better development infrastructure (website, mailinglist, CVS.. kinda what SourceForge does now) but also with more developers.
I realize it's hard (if not impossible) to start an open source project as such - in fact I noticed it myself. They could however start such a project on their own and then when there is enough momentum to open source it do so and guide it.
Alltogether this might be a very good thing though. All too often I come across dead projects on Freshmeat and regret that noone took over the project. (then again, there have been ocassions where months later the project reappeared and looked very healthy again, so one much be pretty sure a project is dead before trying to foster it)
The interim maintainers that are taking care of the package while there's no official maintainer will make that decision.
This message is provided under the terms outlined at http://www.bero.org/terms.html
The purpose of the project is to keep projects alive with the approval of the previous maintainer(s).
Unless someone can't be contacted (or ignores all queries), we don't intend to create forks on our own (at least not at this time; as you can probably guess if you've had a look at our web pages, we're just starting...)
This message is provided under the terms outlined at http://www.bero.org/terms.html
Good idea... I'll add that in the next version.
(As you can probably tell from the looks of the web page, the whole project was hacked up in about 2 days. This includes writing the CGI library we're using.)
This message is provided under the terms outlined at http://www.bero.org/terms.html
Hey, this is really cool.. This would be good for a lot of beginning developers to get some real hands on experience without getting in over their heads on a full blown project. The linux communtity never ceases to amaze me with thier neverending list of Good Ideas.
Segfault
segfault@bellatlantic.net
Now, will someone in this program please adopt Mozilla 5/6 and finish it already? :)
Cheers,
ZicoKnows@hotmail.com
Here's my list of things I'd like to see invigorated with new developers so that they compile again or gain functionality.
xfishtank -- just try to compile it on solaris! Should be a lot cooler with more and better fish. Should have an OpenGL fistank
enscript -- need I say more than 1.6.2?
gnuchess -- what happened in 5.0??
aalib -- the 1.3X stuff needs lots of work. If for nothing more than hack value, aalib should continue to be enhanced.
Xaos -- such a cool fractal viewer. Now id doesn't compile anymore for me.
wget -- how long since we had a new relase? Why can't wget handle imap, nntp, ldap...
** anything that uses xmkmf instead of gnu autoconf ** -- ick, ick, ick -- imakefiles just are messy, especially if you want to change defaults.
TeX -- maybe the most impossible to build, install, and configure software package that exists.
I'm sure there are more that I'll think of, but those ones immediately jumped to mind.
What if more than one person wants to maintain a project and can't agree to work together? Is it first come, first serve? Or would they judge qualifications, amount of time able to devote to the program, etc.
What happens if the original maintainer wants back in? Are they allowed back in, even if the new person in charge thinks they have nothing sufficient to contribute?
Will the old/new maintainers have the right to close the source at any point?
love,
br4dh4x0r
People who used to maintain a package and can't do it anymore...
It would be interesting to find out why this happens. My guess is that it's one of the following:
1. health reasons
2. lack of interest in the project
3. "they don't have the time"
My guess is that for most open source projects that go into an unmaintained state, #3 is by far the most common reason. Of course, this is most likely a euphemism for "I have a job now, and I have to concentrate my efforts on something that actually pays the rent".
Instead of finding alternative maintainers, I think it would be immensely useful if the open source community would try to solve the real problem: how do developers of open source software get paid?
Now, I know a lot of people are going to go into flame mode, but try to think rationally about what I'm saying. If open source developers were actually paid for their work, they would be able to spend more of their time working on open source. They wouldn't need to get day jobs writing closed source proprietary software, but instead become full-time open source developers. And who really deserves to get paid anyways? The guys who created the software in the first place, or the guys who took their software, and put it in a pretty box?
I don't know how this could be implemented though. To be considered open source, developers have to release their code in such a way that others are just as able to make a profit off of it as the developer. What ends up happening is that distributors, who spend little or no effort actually developing code comparitively, end up making all of the income, while the actual software developers make none. Hence, they need to get day jobs, hence less time to work on open source, hence open source projects that are lower quality than they could be, and many projects falling by the wayside.
If open source developers were paid a competetive salary for producing open source software there would not only be "more eyeballs" actively looking at the code, but those people would actually be spending a lot more time working on open source, rather than using up their energy working on closed software.
So is there a way developers can make money of the open source they produce? Every time I've asked people about this they always bring up the old "you can make money off support argument". Sorry, that doen't work. I'm not a tech support guy. I'm a developer, I want to write software. I'd like to write open source software (and I do, when I have the time). I can't afford to do it full-time though. Others mention contract work. Contract work generally produces software that isn't particularly useful as open source because it's often "implement this weird thing that only we would ever find a use for" type of stuff.
Utopia for me would be if I could work on various OSS projects like GIMP, GNOME, sawmill, VIM, and my own projects, and make a decent salary (ie: competetive with closed source developers, not a waiter's salary). Ideally, the system would work in such a way that the more useful my contributions to the community, the more I'd make. This is the real world though, and here the open source community seems to feel that free beer is necessary for free speech...
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 line, 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.
A piece of software losing its maintainer is a vague problem for the users of open source software, but in the closed source world losing the maintainer is a really rather dangerous problem which will slowly get worse and worse as time passes from the time the maintainer goes away. If your hardware changes and the program doesn't like it, or you need a bug fixed, too bad, because that code is gone and there's no way to fix it.
:) Your project looks very promising, good luck)
So I was just sitting here, looking at UFO, thinking about all the closed-source software that winds up getting abandoned by their parent companies, and i'm starting to wonder: what if UFO could get companies to give them the source to dead products instead of just letting the products die?
Of course, there's no reason for a company to do that; they'd get nothing out of it. So why not make it so they do get something?
Make the UFO part of the FSF. Since the FSF is a registered nonprofit organisation, UFO will thus become nonprofit too. Meaning any "donations" by corporations to UFO would be tax-deductable.
Is there any reason that wouldn't work? I don't know what defines "charity" legally but seems to me it would be pretty hard to claim that releasing software to UFO as open source anything other than helping the public good.
Think about it.
(P.S. If the people who made UFO are reading this.. this is TOTALLY irrelivent, and i realize the site isn't supposed to look that polished, but do do some slight tuning on that huge table in the project list. Adding a couple td bgcolor attributes to distinguish between a cell with a project name, a cell with project data, and an empty cell between projects would only take a minute or so, and it would help readability a _lot_.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts