Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Debian The Almighty Buck

Debian Delayed by Disenchanted Developers 329

Torus Kas writes "Debian GNU/Linux 4.0 was supposed to be due by December 4 and development is currently frozen. Apparently the saga was triggered by disenchantment towards funding of $6,000 for each of the 2 release managers to work full-time in order to speed up the development. Many unpaid developers simply put off Debian work to work on something else."
This discussion has been archived. No new comments can be posted.

Debian Delayed by Disenchanted Developers

Comments Filter:
  • Dumb Editor (Score:5, Interesting)

    by Alphager ( 957739 ) on Wednesday December 20, 2006 @03:48PM (#17316248) Homepage Journal
    The development is NOT frozen. The Packages going into Etch are frozen, meaning that the current versions will get into etch with all the necessary bugfixes. development is on full steam.
  • Pffft (Score:4, Interesting)

    by phrostie ( 121428 ) on Wednesday December 20, 2006 @03:54PM (#17316334)
    i've been running debian/etch(testing) for ages. the whole freeze thing doesn't matter to me.
    i don't know what everyone else has their apt sources pointed at, but the rate of updates haven't changed any that i can see.

    take your time, make it stable.
    then i'll switch to what ever the next one is.
  • by und0 ( 928711 ) on Wednesday December 20, 2006 @04:10PM (#17316618)
    Don't be so anal and patch-happy with mainstream packages. Big projects like Gnome and KDE already do extensive testing upstream.

    You sure about that? I've read recently from an upstream Gnome developer that GTK lacks maintainers ( http://blogs.gnome.org/view/timj/2006/12/20/0 [gnome.org] ), Etch will ship Gnome 2.14 because of unresolved GTK bugs, so what you're saying seems quite wrong...
  • by DrDitto ( 962751 ) on Wednesday December 20, 2006 @04:10PM (#17316622)
    There comes a point where working on open-source software can no longer be a hobby done in spare time. I would think that lots of open-source coders reach this point. Then either you find a company to pay you (e.g., Redhat), or you stop doing it. Software is getting more and more complex requiring more lines of code and more development. Unless one is rich and is doing it for a hobby, people need to get paid for their 8+ hours of work a day. Can complex software really be done in your spare time?

    Ideologically, I support Microsoft rather than Linux because Microsoft allows people like myself to make a living. Granted lots of people do get paid to work all day on an open-source project...companies wouldn't do this unless it gave them a competitive advantage (i.e., Redhat can sell an OS by leveraging the work of others).
  • Re:Was ESR right? (Score:2, Interesting)

    by heroofhyr ( 777687 ) on Wednesday December 20, 2006 @04:44PM (#17317084)

    I think you're talking about this:

    If the conventional, closed-source, heavily-managed style of software development is really defended only by a sort of Maginot Line of problems conducive to boredom, then it's going to remain viable in each individual application area for only so long as nobody finds those problems really interesting and nobody else finds any way to route around them. Because the moment there is open-source competition for a `boring' piece of software, customers are going to know that it was finally tackled by someone who chose that problem to solve because of a fascination with the problem itself--which, in software as in other kinds of creative work, is a far more effective motivator than money alone.

    and/or this:

    Indeed, it seems the prescription for highest software productivity is almost a Zen paradox; if you want the most efficient production, you must give up trying to make programmers produce. Handle their subsistence, give them their heads, and forget about deadlines. To a conventional manager this sounds crazily indulgent and doomed--but it is exactly the recipe with which the open-source culture is now clobbering its competition.

    The quotes in themselves aren't fully summing up the idea, but I didn't think it would be wise to cut and paste the whole chapter(s) in this post. The first quote is from the chapter "On Management and the Maginot Line" in tC&tB [catb.org]. The second quote comes from the chapter "Gift Outcompetes Exchange" in Raymond's Homesteading the Noosphere [catb.org].

  • by asuffield ( 111848 ) <asuffield@suffields.me.uk> on Wednesday December 20, 2006 @04:52PM (#17317222)
    Cut the distro down to what will fit on one CD (two max). That will reduce a lot of Debian's headaches. Less for them to maintain and less to test between releases.


    That will accomplish nothing. You clearly don't understand how Debian is developed. Each package is maintained by people who care about getting that particular package in the next release. If it's working at that point, it goes in. If it isn't, it gets thrown out, and nobody else wastes any time on it. There is no conceivable reason why throwing out the stuff that already works would make things any easier - and the stuff that doesn't work is already thrown out. Size is not the problem.

    Don't be so anal and patch-happy with mainstream packages. Big projects like Gnome and KDE already do extensive testing upstream. Those packages should be able to move more quickly through the unstable-testing-stable cycle without sacrificing stability or extensive patching.


    You have clearly never attempted to maintain them downstream. All that 'extensive testing' they do upstream? It's on Redhat, or SuSE, with their own extensively patched versions, tested for the purposes which their paying customers just happened to be using. Fine if you're doing the same thing as them. Useless if you aren't. Does not even attempt to fix the huge numbers of bugs introduced with each new upstream release of these projects.

    Redhat and SuSE find loads of bugs with their testing, and send the fixes back upstream.... to be included in the next release. Which has had more new bugs added. Nobody serious ships the unmodified upstream code, it's just used as a common base for patching and propagating patches between distributions.

    How much of the debian patching on these type of big projects is *really* functionally necessary versus "I 'm the debian package mantainer and I want to put my mark on it".


    Almost every single patch applied to a Debian package is made in response to bug reports filed by Debian users (most of the remaining handful is for policy compliance, portability, or licensing issues). Debian maintainers are far too lazy to go inventing new work to do when there are thousands of outstanding bug reports against these 'extensively tested' packages, listing all the ways in which they suck and need to be fixed.

    (I'm an ex-Debian developer who quit for personal reasons)
  • by CantStopDancing ( 1036410 ) on Wednesday December 20, 2006 @05:19PM (#17317642)
    How about a special package (call it apt-repo or something) that is a list of somewhat-blessed unofficial repositories? This can be updated fairly frequently, with contributors (either debian project members, or other existing package maintainers) adding their own repositories. These then get built into sources.list - the package's only functional file. A simple apt-get install apt-repo merges the updated sources with the system's current copy. Presto chango! A neat debianesque way to preserve the existing set of packages while trimming down the core.

    Of course, there will need to be some way to ensure only blessed repositories make it into the meta-package, but that shouldn't be hard to do - the existing maintainers/ mentors system is effectively just that, after all.

  • by wrook ( 134116 ) on Wednesday December 20, 2006 @05:23PM (#17317734) Homepage
    > Can complex software really be done in your spare time?

    Yes.

    The fact that many people *also* get paid to work on Free software is beside the point. You can write complex software in your spare time.

    The interesting question is: how do we scale up development so that we can have large numbers of people working on the same code base, while they each only put in an hour or so a day? In the Free software world there are many examples of fantastically large teams that seem to create content without the problems you see in the average proprietary shop.

    Some of these things have to do with the nature of Free software. For example: the ability to fork development any time that you want; the lack of need to get approval for work to begin; the ability to use evolutionary rather than planned process (i.e., any crackpot can implement a feature and the choice of whether or not to add it to the mainline can be made after the fact *without significant cost to the project*).

    Yes, having a team of full time developers has some advantages. But it is far from impossible to write code with volunteers. And there are definite advantages to working in such an environment (I have done both in my career).

    Having said all that, my preference is for Free software that is supported by full time programmers and for which I can buy a support contract. If it's mission critical software, I want a support contract and I want it to specify that the supporter will fix bugs that are stopping me from achieving my work (something which I've found difficult to find in the proprietary software world).

    Failing that, I'll definitely take source code over vague promises that my problem might get fixed in a subsequent release if several other people seem to be having similar problems and the vendor is still in business...
  • by Kjella ( 173770 ) on Wednesday December 20, 2006 @05:57PM (#17318348) Homepage
    In fact what you and many other people miss is that no one does something for nothing. (...) They are being paid in good feelings.

    Yes, but I don't think it's primarily the "I need to get paid" feeling which is tickled here. I think it's the feeling of fair. It's a very tricky feeling, and has nothing to do with technical or license issues. While there are paid developers which can be seen as a form of kickback by commercial distributions, the community itself is mostly built on common interest.

    That common interest is like "you scratch my back, and I'll scratch yours", "we're all in this together pulling against the same goal", potluck dinner and so on. Once the focus shifts to attracting sponsors, it's every man for himself like if it was a beauty contest. Also I just had a horrible image of the swimsuit show, and now you do too. Anyway, the point is that it's not "why aren't I getting paid?" as much as "why should we be paid differently?"

    For one you have the "It should have been me!" people, but there's also the "Now we're paying someone to do it" people. I must admit I'd have a pretty hard time motivating myself to do unpaid work to relieve someone who's getting paid. Even if I work 2hrs/week and you 40hrs/week, I have a pretty hard time accepting that you should be paid $X/hr and me $0/hr. Certainly, some people have "earned" it in my eyes, but if the feeling is "They're doing exactly the same as the rest of us, except they get paid" would you put up with that?
  • Re:Dumb Editor (Score:3, Interesting)

    by msobkow ( 48369 ) on Wednesday December 20, 2006 @06:07PM (#17318496) Homepage Journal

    I know a lot of people using Debian and other distros. With the OSS licensing, I don't see why Debian doesn't get more respect for focusing on stability.

For God's sake, stop researching for a while and begin to think!

Working...