Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
News

Adopt-a-Free-Software-Project Program Launched 71

Posted by Hemos from the cool-idea dept.
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."
This discussion has been archived. No new comments can be posted.

Adopt-a-Free-Software-Project Program Launched More

Adopt-a-Free-Software-Project Program Launched

Comments Filter:
  • bugs fixed in the past week

    That's as maybe, but last night's Windows build crashed on my office machine within eight pages, and still has problems with the "back" button (hit back, nothing happens, hit it again and it goes two pages back.) I'd like to help out, but unfortunately apparently there's no way for me to get a meaningful stack trace with the Windows build which I think could be fairly helpful.
  • I'd just like to say that yes, this has been needed for a very long time. This happens more often than not amongst the Quake community in particular. I'm thinking of the Quake 1 mod Quake Rally here. When Quake 2 was released, the project leaders put it on hold and eventually abandoned it. It was a good mod, but it would have been far better had it been completed. As it is, when a group of people contacted the authors with the intention of restarting development, they were informed that the original source had been lost in a hard drive failiure. Now, had the UFO program been around back then, there's a very good chance that Quake Rally would have been completed.

    As for your questions, Well, I can't answer your first one, but the second two I think I can field.

    1. If the original author wants back in, but the current maintainer isn't really into that, what's to stop them from simply starting a parallel project, based on the original source?
    2. According to the GPL, once a project is open-sourced, people have the right to use the source to build upon. However, they do not have the right to make that closed-source. They have to provide the source to anyone who wants it.

    -- Chris Dunham
    http://www.chamdex.com
  • int main(int argc, char **argv)
    {
    }

    Then drop it off as unmaintained code. ;)

    That would be a nice work around, but it doesn't cover the problem that starting an open source project is almost impossible without an existing codebase.

    In case a project would *still* not be maintained, how much time and effort will Red Hat put into it? I understand you'll do basic maintainance and patches for project if/when noone else does, but this doesn't apply to very fresh ideas/projects.

    Also, do you cooperate with parties such as Gnome (obviously?), KDE, etc? I could imagine that an abandoned Gnome or KDE project would best be taken over by someone active in a group related to the project.


  • 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... ;))


    I'd have a couple of issues working for Red Hat, or any other distro.

    First, while Red Hat does hire developers, the developers don't contribute to the the product that Red Hat actually sells. Red Hat's product isn't software, it's distribution and support.

    This means that Red Hat doesn't need its developers to stay competetive. Imagine that another distribution started to seriously cut into Red Hat's profits, and Red Hat figured that it needed to cut costs. The easiest way to do that is to lose the developers. After all, they don't contribute to the bottom line. In fact, the developers are helping that competing distro just as much as they're helping Red Hat, so it makes little difference to Red Hat who they work for (or if they work at all). If this seems far-fetched, consider the fact that Mandrake has won a few awards, even though it's only a slightly modified Red Hat. Mandrake is standing on Red Hat's shoulders, so to speak, yet they don't contribute to the salaries of Red Hat's developers. Consider also that Red Hat has to compete with non-distro support sellers like Linuxcare (which doesn't hire any open source developers, AFAIK).

    The only thing that would stop Red Hat from firing their developers in that situation would be the bad PR. That's only the case because most Linux users have an "open source conscious", so to speak. I wouldn't like having my job only because of PR reasons.

    The other issue is the whole conflict of interest thing. Red Hat relies on support for income. If Linux were really easy to set up and use, people wouldn't need to buy Red Hat's product. So it's against Red Hat's interests to make Linux too easy to use, or they won't get any profits.

    Now, that's an over simplification. There is some incentive for support-sellers like Red Hat to improve Linux. The easier Linux is to use, the more people will consider using it. Since some percentage of those people will buy Red Hat's distro, that's good for Red Hat. But consider also that the easier Linux is to use, the higher the percentage of Linux users that will decide they don't want to pay for support, since they won't ever use it. That means that at some point there's an equilibrium, and beyond that, the easier Linux becomes, the less profit support sellers like Red Hat make.

    Contrast that with proprietary software, which often makes little or no profit from support. Support fees are often there just to deter trivial help requests, and to cover the cost of hiring support personnel. So there isn't a conflict of interests, and there is in fact an incentive to improve the software, as the easier it is to use, the more profits are made from sales.

    The root of the problem is that people want to use the software, but they don't want to pay for the work that went into producing it. Instead they want the developers to find an alternative source of funding, all the while hoping they can side-step it. They say, "why not give the razor [software] away for free, and charge for the blades [support]?" The problem is, it's developers' responsibility to make the razor so good that the blades are unnecessary, thereby cutting off (no pun intended) their only potential source of income.
  • Uh... not a bad idea, but not a complete solution I think. Income tax write-offs aren't very useful if you don't have any income to start with.
  • TeX -- maybe the most impossible to build, install, and configure software package that exists.

    You gotta be kidding. ./configure; make; make install. All you need is an ANSI C compiler. I compiled it on OpenBSD ( on which it's difficult to compile a lot of Linux packages ) without a hitch.. To configure it, just run "texconfig".

    The main reason why there is some complexity in aspects of configuring tex ( eg adding fonts or macros ) is that it is a large complex package. But they seem to be working on it.

  • Maintenance
    Of
    Open-Source
    Software
    Encountered
    Desertion

    And you can say that an unmaintained project has been "moosed".

    Ok, so it's dumb, but a little brainstorming never hurt anyone. :-)
  • What will happen if UFO is abandoned?
  • If you're good, send your resume to Red Hat.
    If you aren't, try one of the other distributors... ;))

    That's easy for you to say. There's not enough opening at all the Open Source companies combined to hire all the Open Source developers. You're just side stepping the issue. Your employer is currently making (losing) its money through support and proprietary addons. Some of us would like to make money off of Open Source Software development.
  • if a project finds a new maintainer, and then the old one comes back, the project should take advantage of it, because they now have two maintainers.
    look at the history of Window Maker:
    alfredo kojima had to leave because he had a job in japan for some time. dan pascu took over.
    eventually (it was about a year later i think) alfredo came back. and since then alfredo and dan are happly leading the project together.
    Window Maker only benefited from that.

    greetings, eMBee.
    --

  • hmm..how does this work ? I have apps ive not been working on because they do everything i need them to. however, do they qualify as unmaintained ? I add any patches sent to me and answer email but thats it. no new features. should i drop em off at your site ?
  • On the other hand, having open source projects run by volunteers offers a very nice bloat-filter. If a feature isn't really needed, it won't get added.

    Nobody's going to bolt on some half-baked feature that nobody wants, just because it's their job to maintain it, and by gosh they'd better look like they're doing something.
  • Why not have the acronym be "UFOS" (Unmantained Free Open-source Software). That's much more grammatically pleasing and easier on the tongue. Plus, the "S" makes "UFO" plural, and since there won't be just one project listed...
    ----
    Lyell E. Haynes
  • As long as the author doesn't reassign the copyright to the new maintainer, he should still be allowed to close his source. The new maintainer's still have code the code they licensed under GPL, and have the rights to keep distributing that. So they can try to change it, but since it's already been distributed there isn't a legal way to close all of the source out there.
    treke
  • _linux_ community?

    More like open-source community.

  • TeX -- maybe the most impossible to build, install, and configure software package that exists.

    Sorry, but this award would go to either IRAF or AIPS (astronomy image analysis programs.)
  • Hey, did anybody think of the fact that quite a number of these UFO projects may have been abandoned for a good reason?

    If nobody picks up the project spontaneously, then it's not very likely to be worthy. Why not direct the people who want to contribute open source to the projects that will really make a difference?
  • Perhaps you should add....

    4. they get bored with that piece of code they developed. How many years can any person look at one piece of code anyways before needing a new challenge?

    5. they acquire a family they have to feed with littl'uns that have to be sent to college. There goes that bohemian worry-only-about-me lifestyle.

  • As for your last point, I believe that the whole issue with Mattel and the CPHack program centers around a copyright holder's right to revoke a free lisence. AFAIK, the GPL has clauses in it that say that once you've got a GPLed copy of a program, the author can't do anything to restrict your rights under the GPL. Including revoking the lisence.

    As for the other two, remember that the basic element of multi-task programs can also be applied to free programming projects: Code Fork!


    -RickHunter
  • Is it possible to get decent performace out of root window updates? A while ago there was a small utility released on themes.org that would take a pixmap and animate it on the root window, sliding/floating it around. It was a neat effect, but unless you set it to a delay-so-long-its-not-really-animated-anymore, it sent processor usage to 100%. Is this a deficiency in X, that root window updates are slow, since they werent really meant to happen that often?
  • Why are you accepting packages for crappy OSes???
    An open-sourced package for a crappy OS is just an open-sourced package for a good OS that hasn't been ported yet...

    Pretty much says it all. :)

  • Why are you accepting packages for crappy OSes???
    An open-sourced package for a crappy OS is just an open-sourced package for a good OS that hasn't been ported yet...

    And what about packages that simply cannot be ported? For example, there's fsdext2 [demon.co.uk] -- an ext2 fs driver for Windows 9x. It is a very useful thing (it makes your Linux partition available to all applications with a drive letter, unlike Explore2fs/ltools/whatever), but it makes no sence to port it to a "good OS".(I'm assuming Slashdot's popular notions of "good OS" == "Linux/*BSD", and "crappy OS" == "Microsoft *".)

    I've already notified the maintainer (who hasn't been actively developing fsdext2 for quite some time) about UFO.

  • If the application is used for common tasks, you'll always have a good maintained replacement for the dumped package.

    If it is a highly specialized application, shortly after geting used to it, the company will start customizing the sources, so no external maintainer will be needed.

    So the "NO ACCOUNTABILITY" is a fake problem created by M$-type IT managers who do not understand what is the Open Source about.
    The Open Source software decreases the ability to hide their incompetence behind the poor quality of the software they buy using big money substracted from the shareholders' pocket.
  • What if people writing open-source software were able to write off the time at a reasonable rate: say [if they were self-employed] as a business development expense or [otherwise] as a donation?

    I'd think that if this practice could fly, open-source would really flourish.

  • They'll have to form an Adopt-a-Free-Software-Project-Project
  • This is a great idea. I've had several programs I used on a regular basis, go the way of the dodo in the past. We'll see if this is sufficient to keep that from happening.
  • There seems to be lots of people who would
    gladly do something about DMCA, UCITA, Patents
    and all things discussed here under topic Your
    Rights Online. Only thing needed is somekind of
    organization or group who would make it EASY for
    people to participate in demonstrations and other
    acts. So any ideas or willing people to form
    something like this? And the idea of passing the
    leadership is very good making the "movement"
    more continuous and relieving the burden of
    those responsible.
  • It would be really great if someone established a non-profit orginazation (I'm an student/soon to be engineer so sue me if i can't spell) that could be run on contributions by the community that would hire people to work full time on Open Source Projects. The coders would get paid from mthe money of the contrubutions...and the community would get solid peices of Open Source Software that would be updated reguarly.
  • Err, that would be against DMCA.
  • Who decides the maintainer is competent enough?
  • CoSource [cosource.com] is IMHO a very cool attempt at an implementation of that idea; I noticed while double-checking the URL that Apache's gained a feature thanks to their efforts. I especially like that a common response to a pending project is to point out that some arcane software package nobody's (read: I haven't) ever heard of will do it for you, and/or it's easy if you use the XYZ library/technique (usually with a URL). People almost get pissed off when they get offered money for something that's trivial.

    OTOH, from the very limited amount of attention I've given it, it doesn't seem like that many people are getting paid -- there are a lot of semi-cool-sounding projects with $10 committed to them, and a lot of projects that have stagnated once half the amount needed was raised. If this impression is accurate, then it's a terrible shame.

  • How about this:
    Someone sets up the "Open Source The World" website, with lists of oh, say, the 200 most popular commercial apps, and people can come in and start projects to make better apps that are Open Source.
    I like the idea of getting maintainers for the old stuff, too. But I think the community is missing some kind of overall view of the 'market' (so to speak, don't cringe).
    Hmmm... I just checked and ostw.com is taken. Maybe "OSTU(niverse)" is more suitable anyways. I mean, there could be alien races out there with big, evil, monopolist corporations too.
  • It sounds like a great idea - kind of like an "Adopt-a-Dying-Program" foundation - it'd be useful for software that interests the users but the author doesn't feel like continuing anymore. Of course, the next question: How does the foundation choose what person (or group of persons) picks up a project?
  • Looking for developers - take a look [eunuchs.org]...

  • :) (Score:2)

    by mattdm ( 1931 )
    ah yes. obviously they'd be much more productive with that "6" editor.

    --

  • 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)
    /||\
  • 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)
    /||\
  • 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)
    /||\
  • The reason I am not allowed to run linux at the office, is that there is NO ACCOUNTABILITY

    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.

  • 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.
  • 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.

    ========
  • "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.
  • wget -- how long since we had a new relase? Why can't wget handle imap, nntp, ldap...

    It can't handle cookies or SSL either. (well, cookies can done with a hack [cc.fer.hr] , but it's a pain. it'd be much nicer if you could just point [cc.fer.hr] 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.
  • Have you looked into wxPython [alldunn.com]?

    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... ;))
  • 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.
  • 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".
  • 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.
  • 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...
    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 [freefilm.cx] for another fine example of me not being able to pick names ;) ) - but improvement is what open source is all about: If you have a better name, let us know.
    I'd rather have a project without a fancy name up and running than just delaying it forever.
  • 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.
  • 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.


    =================================

  • xsprite (xfishtank) (Score:3)

    by Frank Sullivan ( 2391 ) on Thursday March 30, 2000 @11:24AM (#1160340) Homepage
    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)
    /||\

  • Very cool (Score:3)

    by Rob Kaper ( 5960 ) on Thursday March 30, 2000 @10:50AM (#1160341) Homepage
    Keeping a program alive is very important for open source.

    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:

    • Maintained programs that could use more manpower but have been unable to harness more volunteers.

      They could help such program to create a better development infrastructure (website, mailinglist, CVS.. kinda what SourceForge does now) but also with more developers.

    • Neat program ideas that simply haven't been turned in a project yet.

      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)

  • Re:maintainers (Score:3)

    by bero-rh ( 98815 ) <bero AT redhat DOT com> on Thursday March 30, 2000 @11:26AM (#1160342) Homepage
    The interim maintainers that are taking care of the package while there's no official maintainer will make that decision.

  • Tell the maintainers then... (Score:3)

    by bero-rh ( 98815 ) <bero AT redhat DOT com> on Thursday March 30, 2000 @12:00PM (#1160343) Homepage
    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...)
  • 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.)

  • Re:Very cool (Score:3)

    by bero-rh ( 98815 ) <bero AT redhat DOT com> on Thursday March 30, 2000 @12:43PM (#1160345) Homepage
    Starting an open source project is very possible without an existing code base; most of the bigger projects started from scratch.

    Despite the fact that the project started out at Red Hat, is run by a Red Hat developer and has several other Red Hat people backing it, this is not officially a Red Hat project, so (for now) the question is not "how much time and effort will Red Hat put into it", but "how much time and effort will YOU put into it" - it's a project that needs participants. We need people to help maintaining packages, both true maintainers and interim maintainers.

    There's no guarantee that a project started out being dumped while in the main() { } phase will get anywhere. There's no guarantee of the opposite either.

    As for cooperating with other parties, the answer is "ideally yes" - but of course we can't force anyone to help us out.

    But knowing the nature of open source, my guess is that at least most of the time, this type of cooperation will work.

  • Super! (Score:3)

    by segfault7375 ( 135849 ) on Thursday March 30, 2000 @10:34AM (#1160346)
    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 [mailto]

  • Sweet. (Score:4)

    by Zico ( 14255 ) on Thursday March 30, 2000 @10:40AM (#1160347)

    Now, will someone in this program please adopt Mozilla 5/6 and finish it already? :)

    Cheers,
    ZicoKnows@hotmail.com

  • some suggestions for projects needing new life (Score:4)

    by poopie ( 35416 ) on Thursday March 30, 2000 @11:03AM (#1160348) Journal
    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.

  • Re:Very cool (Score:4)

    by bero-rh ( 98815 ) <bero AT redhat DOT com> on Thursday March 30, 2000 @11:24AM (#1160349) Homepage
    We can already do that...
    Write a README, and a piece of code saying something along the lines of

    int main(int argc, char **argv)
    {
    }

    Then drop it off as unmaintained code. ;)

    Chances are I (or another admin) will approve the package if the idea is interesting enough.

  • Problems? (Score:4)

    by br4dh4x0r ( 137273 ) on Thursday March 30, 2000 @10:38AM (#1160350)
    Things I didn't see answered in the FAQ...

    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...

  • Adopt-a-Coder (Score:5)

    by Signal 11 ( 7608 ) on Thursday March 30, 2000 @11:05AM (#1160352)
    I'd like to also announce the adopt-a-coder program. After working 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 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.

  • i have a wierd idea here. (Score:5)

    by mcc ( 14761 ) <amcclure@purdue.edu> on Thursday March 30, 2000 @03:34PM (#1160353) Homepage
    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.

    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_. :) Your project looks very promising, good luck)

  • Re:Problems? (Score:5)

    by bero-rh ( 98815 ) <bero AT redhat DOT com> on Thursday March 30, 2000 @11:01AM (#1160354) Homepage
    Since I created the project, I guess it's up to me to answer this...
    • This one is more or less answered in the FAQ. Temporary maintainers will just have to work together. Real maintainers are supposed to tell the temporary maintainers where they want to take the package, and show at least a patch to show they can do something.

      Aside from that, first come first serve - once a package has found a new maintainer, it'll be removed from UFO (we can continue hosting it though).
    • I haven't really thought about this, but I'd think someone who has maintained a program before will always have something to offer (experience, for instance). I guess it'll be a bit dependent on the particular package.
    • This depends pretty much on the license - unless it's not open source, we don't intend to change licensing.

      The BSD license in general permits closed-source forks, the GPL doesn't (and licenses can't be changed without the consent of all contributors)

    I'd welcome feedback on these and other issues very much - if you have any thoughts on this, let me know (either here or at bero@redhat.com [mailto])

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close