Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Top Linux Developers Losing the Will To Code?

Posted by CmdrTaco on Mon Jul 02, 2007 10:19 AM
from the will-hack-for-food dept.
E5Rebel noted that Don Marti has a piece that talks about "Core Linux developers are finding themselves managing and checking, rather than coding, as the number of kernel contributors grows and the contributor network becomes more complex."
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • This is Bad? (Score:4, Insightful)

    They're probably getting older, too.

    Perhaps the less coding you do the higher you get up in the management ladder is for a reason, after all...
  • will has nothing to do with it (Score:5, Insightful)

    by Anonymous Coward on Monday July 02, @10:25AM (#19717835)
    the talented get promoted to managing because they care about what's happening, how it gets done, and they know what's going on. This doesn't equate to "I don't feel like coding" as the article suggests.

    "That's all I do, is read patches these days," he said during a discussion at the Linux Symposium in Ottawa last month.

    This doesn't read "I don't want to code" it reads "I haven't time to code"
  • a good or bad thing? (Score:5, Interesting)

    by brunascle (994197) on Monday July 02, @10:25AM (#19717839)
    that's odd. the linux.com article [linux.com] covering the same event made it sound like the kernel team thought it was a good thing that there were more developers, and the work was more spread out.
    • I think the question is more ... (Score:5, Insightful)

      by khasim (1285) <brandioch.conner@gmail.com> on Monday July 02, @10:37AM (#19718015)
      ... how has the amount of code they actually approve and that gets into the kernel changed?

      Once you become a guru coder, you may write less code yourself, but you may approve more code over all. That would be code written by other people that you check, tell them where the bugs are and they fix the bugs and re-submit the code.

      When the code is up to your standards (and the evidence is the flat rate of bugs) then the code is included in the kernel.

      There was a time (long ago) when Linus wrote ALL of the code himself. If you look at just that metric, Linus barely writes anything anymore (percentage-wise).
      [ Parent ]
      • Re:I think the question is more ... by timeOday (Score:2) Monday July 02, @01:31PM
      • Re:I think the question is more ... (Score:4, Insightful)

        by zCyl (14362) on Monday July 02, @01:45PM (#19720423)

        When the code is up to your standards (and the evidence is the flat rate of bugs) then the code is included in the kernel.

        There was a time (long ago) when Linus wrote ALL of the code himself. If you look at just that metric, Linus barely writes anything anymore (percentage-wise).

        This of course implies that code is now checked more times and more carefully BEFORE inclusion, which is a win for everyone.
        [ Parent ]
    • Re:a good or bad thing? by bjourne (Score:2) Monday July 02, @11:33AM
  • So? (Score:3, Insightful)

    by Actually, I do RTFA (1058596) on Monday July 02, @10:26AM (#19717851)

    This is what happens as projects get bigger. It's not that they lose the "will to code", it's that they spend all their time as managers of other coders. There's more to developing a large codebase than writing the code after all.

  • Will? (Score:5, Informative)

    by truthsearch (249536) on Monday July 02, @10:26AM (#19717855)
    (http://seenonslash.com/ | Last Journal: Friday May 11 2007, @04:02PM)
    I read the first page and didn't see anything about them losing their will to code. It seems just the sheer number of innovative contributions means they have more to manage and less to write. This can't be a surprise with so many individuals and companies now contributing.
    • Re:Will? by Anonymous Coward (Score:1) Monday July 02, @11:59AM
    • Re:Will? by Anonymous Coward (Score:3) Monday July 02, @12:08PM
    • 1 reply beneath your current threshold.
  • Git (Score:3, Insightful)

    by CarpetShark (865376) on Monday July 02, @10:26AM (#19717857)
    Isn't this what Linus said that Git was supposed to fix?

    I wonder are the rest using it... I wonder are the rest even delegating.
    • Re:Git (Score:5, Informative)

      by CarpetShark (865376) on Monday July 02, @10:31AM (#19717931)
      To clarify: Linus gave a talk at google, where he spoke of Git as part of the solution to this problem, and his shear lack of interest in helping "subordinate" (my word, for want of a better one, not his) developers. He said, essentially, that if people don't write proper patches, or if they write patches that conflict with other patches, he doesn't spend time integrating: he throws it back, and says do it again. Likewise, he doesn't manage tons of individual patches; he delegates to others, who spread the load. If the "lieutenants" aren't handling their part, they just need to learn from Linus.
      [ Parent ]
      • Re:Git by CarpetShark (Score:1) Monday July 02, @11:02AM
        • Re:Git by DogDude (Score:1) Monday July 02, @11:16AM
          • Re:Git by CarpetShark (Score:2) Monday July 02, @12:22PM
            • 1 reply beneath your current threshold.
          • 1 reply beneath your current threshold.
        • Re:Git by CarpetShark (Score:1) Monday July 02, @12:24PM
        • Re:Git by CarpetShark (Score:2) Monday July 02, @12:27PM
        • 1 reply beneath your current threshold.
      • Re:Git by WindBourne (Score:2) Monday July 02, @11:43AM
      • Re:Git (Score:5, Insightful)

        by Dan Ost (415913) on Monday July 02, @12:10PM (#19719299)
        This is actually an example of good management (or, more correctly, management knowing its own limits).

        Bouncing the patch back to the original author is exactly the correct thing to do. There's no way that Linus can be as familiar with the patch code as the person who wrote it, so why would he think that he could do a better job integrating than the original author?
        [ Parent ]
      • 1 reply beneath your current threshold.
  • by postbigbang (761081) on Monday July 02, @10:28AM (#19717891)
    New projects open all the time. As the FOSS code base increases, it's easier to move code around. Once one takes on responsibility for a project, the new code vs maintenance code is always going to change. And there are thousands of projects where someone gets bored, moves on, or whatever, where the project then becomes stuck in the mud. SourceForge is full of them. It doesn't mean there's anything wrong, it's the fits-and-spurts of how coding works.

    Nothing to worry about. It's natural.
  • by Dareth (47614) on Monday July 02, @10:29AM (#19717903)
    You do not have to be a top coder to help develop Linux. The top developers have the skill sets needed to write and manage code. These talents are needed. The top developers can mentor the next generation/level of talent and raise them up to a higher level. This helps to ensure quality and continuation of so many great projects past the time when the original "guru(s)" have moved on to their next itch.

    Everyone can help in some way. The newbies who read the "Linux Recipes" online and point out areas of confusion are helping. I would even dare say the "Grammar Nazi" who helps correct documentation helps too.

  • Not loosing the will (Score:2, Interesting)

    by realdodgeman (1113225) on Monday July 02, @10:34AM (#19717973)
    (http://datanytt.no/)
    They are not loosing the will to code. They just have too much other work, like reviewing others code. So they do not have enough time left to code. RTFA. The headline is not reflected in the article itself at all.
  • The Mythical Man Month (Score:5, Interesting)

    by $RANDOMLUSER (804576) on Monday July 02, @10:35AM (#19717983)
    Described this in 1975. As you add more people to a project, communication takes up more time than coding. From Wikipedia [wikipedia.org]:

    Assigning more programmers to a project running behind schedule will make it even later, due to the time required for the new programmers to learn about the project, as well as the increased communication overhead. When N people have to communicate among themselves (without a hierarchy), as N increases, their output M decreases and can even become negative (i.e. the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created).

    * Group Intercommunication Formula: n(n 1) / 2
    * Example: 50 developers -> 50(50 1) / 2 = 1225 channels of communication

    • Re:The Mythical Man Month (Score:5, Insightful)

      by flaming-opus (8186) on Monday July 02, @10:47AM (#19718133)
      This assumes that the kernel is a single common software project.

      It isn't. A few filesystem developers might have to make changes to elevator, or allocator code, but most developers of XXXXfs don't really need to make changes outside of that directory. Developers writing a driver for the XXXX model scsi controller, don't really need to interact with the people mucking with Alsa, or gart, or whatever.

      The kernel might be contained in a single source repository, but it's really a few hundred, mostly-independent software projects.
      [ Parent ]
    • Re:The Mythical Man Month by eMbry00s (Score:2) Monday July 02, @12:38PM
    • Re:The Mythical Man Month by Omnifarious (Score:2) Monday July 02, @02:41PM
    • 1 reply beneath your current threshold.
  • Book needed (Score:2, Offtopic)

    by jshriverWVU (810740) on Monday July 02, @10:36AM (#19717999)
    There really needs to be a howto or book on how to write a linux device driver. I feel even more people would be willing to help out if they had a bridge between "just learn C" to "you're now a kernel guru"

    Granted if you're a good enough programmer you can traverse the source tree and pick up things on your own, but that is very time consuming versus "here's a quick overview" then look at the code for specifics.

    • Re:Book needed (Score:5, Informative)

      by fattmatt (1042156) on Monday July 02, @10:42AM (#19718075)
      (http://www.backfire.net/)
      [ Parent ]
    • Re:Book needed by holden caufield (Score:2) Monday July 02, @10:46AM
    • Re:Book needed by quanticle (Score:2) Monday July 02, @10:49AM
    • GregKH driver tutorial by ezh (Score:2) Monday July 02, @10:55AM
    • Re:Book needed (Score:5, Insightful)

      by MROD (101561) on Monday July 02, @10:55AM (#19718265)
      (http://www.lingula.org.uk/)
      The problem is that with almost every minor kernel version revision the driver interface is changed, so any book that goes into print will already be almost worthless by the time it got into the shops.

      This is why the current fluid kernel/driver interface specification is unsustainable and unmanagable in the long term (and why ultimately the kernel development process will bog down).

      The solution? Simple, separate the core kernel from the drivers and produce a specification for the interface which only changes with the major kernel version. Then the kernel developers can concentrate on the pure internals of the kernel which no-one but them should need to know about and the work which currently takes place to recode the hundreds of drivers each time there's a tweek to the driver interface could be redirected to more productive efforts... and the patch load should be less as well.

      There is a side benefit to this as well, the energy barrier for 3rd parties to write drivers would be lower and hence it would be far more likely that they'd actually write them rather than management seeing the driver maintenance and support costs being too high to bother because of the constant code churn.

      I know that there are many people who will veremently disagree with this because of the dogma saying, "the kernel hackers know best about the kernel so they should be the same people as those who write the drivers." There will also be those who believe the dogma of, "but the driver interface needs to change often so as to be Better(tm) so you can't set the interface in stone."
      [ Parent ]
    • Re:Book needed by Hognoxious (Score:2) Monday July 02, @11:02AM
    • OMG, u r teh 733t! by edittard (Score:1) Monday July 02, @11:15AM
    • 1 reply beneath your current threshold.
  • It happens in every aspect of IT, or certainly the ones I have been involved in. As manpower increases, the longest served ops, sysadmins, programmers, whatever, get more responsibility pushed on them and therefore do more managing and less of what they were hired to do. Linux is a classic case of a large scale software project and I would expect the 'names' of the project to do less, perhaps even against their wishes. Someone mentioned Git, which is a very good way of managing this kind of project, but I guess that would take a form of its own and end up with some people managing and others contributing code. So the wheel goes on...
  • Maximize value (Score:2)

    by nuggz (69912) on Monday July 02, @10:52AM (#19718225)
    (http://slashdot.org/)
    If you only have X hours to spend on a project you should choose the activities that will be most beneficial.

    As much as technical guys don't want to think about it, good management is an excellent productivity multiplier, alternatively no/poor management is a productivity destroyer.

    Some well directed management and control will often result in the team getting more additional work being done than if the "manager" did it himself.

    Think about all the times the senior guy, or the suits rejected blocked or otherwise stopped something you thought had great value. You should consider that perhaps if YOU were the manager, some of those good things would happen, you might be more useful doing the managing than technical work.
  • As the number of contributors grow and the network becomes more and more complex you NEED management who understand the task at hand. Dilbert, and I'm sure most people out there, suffer from BAD management. We all know how bad management can doom a great project.

    I am sure that they miss coding but are they working on linux to satisfy their own coding desires or to make linux a better product. If it is the former then they have no reason to be in management, but if it is the later then they are needed where the are. As the network gets bigger and more complex we are going to need people who have a better grasp of the BIG picture. Without this linux will die.
  • by SolusSD (680489) on Monday July 02, @10:59AM (#19718327)
    (http://www.solussd.com/)
    ...and ike any long term programming project new people will replace the once core coders and will be overseen by previous core coders. why is this news?
  • Welcome to programming (Score:3, Insightful)

    by hikerhat (678157) on Monday July 02, @11:00AM (#19718335)
    This is how it always works. Once you have enough experience doing anything, from building houses to writing code, you start to spend more time sheepherding the less experienced and less time implementing. It's the circle of life. I didn't rtfa.
  • Where's the beef? (Score:3, Insightful)

    People simply tend to get more managerial as they get older. This extra proofreading, checking and review has resulted in a fantastic product. While BSD is my primary computer interest, I've maintained a Linux box since 2.6.16 to follow the most current developments. I'm running 2.6.22 now and have great respect for the way they use SMP to enhance reliability. Short of a hardware failure, it simply doesn't crash. The way I use a computer, getting an hour uptime out of XP would be rather remarkable.

    BillSF

  • Within every IT organization I have ever dealt with, Open Source or not, all but a few of the most talented programmers inevitably move to code oversight roles, and for a simple reason: their knowledge of the "why(s)" in the code becomes vastly more important than the code itself. Consider these two:
    • Samba (for example): Which is more important now, for the original coders to write new code, or do be able to oversee the current code base and insure nothing that M$ can use as a "we own the patent" hammer creeps into the code.
    • Data quality and security conformance to government rules: which is more important for the talented programmer, to write new code, or make sure that the code as written and the data rules as written meet Sarbanes Oxley compliance?
    The other aspect of code oversight being a role for the most talented is the fact that programmers in the 18-35 age range tend to be willing and able to put in the extreme hours of coding time required for prodigious quantities of code, but there is no guarantee of quality without oversight by a more experienced hand. So one senior coding guru's guidance of many newer programmers is a much better use of time.
  • Circle of life! (Score:2)

    by ceeam (39911) on Monday July 02, @12:06PM (#19719243)
    More appropriate caption would be "Top Linux developers are replaced with new ones as time go by".
  • Stop the presses! (Score:2)

    by MrZaius (321037) on Monday July 02, @12:15PM (#19719347)
    (http://192.168.0.1/)
    Stop the presses, stop the presses! We've got to go with a new lead story: "People gain experience, get old, assume managerial positions!"

    Wow.
  • by Fractal Dice (696349) on Monday July 02, @12:15PM (#19719359)
    (Last Journal: Monday September 06 2004, @05:06PM)
    They haven't stopped coding, they just code in a higher language - just as C can take care of all that dirty assembler for you, a human coder can take care of all that dirty C. You just sit back, watch the code flow past, filter it and nudge it in the directions you need it to go. It's bleeding edge technology, it's just the system requirements are a little steep for most of us to assemble - give it a few decades and I'm sure we'll all be coding this way :)
  • Decaf ! (Score:3, Funny)

    by Marbleless (640965) on Monday July 02, @12:39PM (#19719615)
  • Reviewers are important. Just about anyone can write code. It takes much more skill to analyze somebody's else writing, think about impacts, possible bugs etc. Reiser4fs was stalled so long because there was no person simultanously fluent in filesystem and willing to review its codebase.

    Reviewers are often unrewarded for their work. At the end of the day, person who wrote code takes credit, not all those nitpickers who helped raise the code quality.
    • 1 reply beneath your current threshold.
  • Wii? (Score:2)

    by Monoman (8745) on Monday July 02, @01:02PM (#19719865)
    (http://www.cafepress.com/gotmpg)
    I read Wii (instead of Will) at first and second glance. I don't have one but it is obviously in the headlines too much. :-)
  • Fundamental Flaws (Score:5, Insightful)

    by rAiNsT0rm (877553) on Monday July 02, @01:31PM (#19720243)
    (http://teasphere.wordpress.com/)
    I spend a lot of time online trying to get through to folks on this issue but everyone just blows it off. I have been a Linux user/contributer for over 12 years now and have nothing but the best interests in what I say. The biggest problem is the fact that the only area to have any management and direction is the kernel. The rest is far too chaotic and self-serving to ever become a cohesive system.

    Some examples: OS X. In ten years or so a fairly small team has taken BSD and turned it into what it is. In over 12 with Linux I still see many of the same issues and problems persist... why? Because Apple *focuses* their efforts and the entire project is properly managed and steered. Imagine with the same focus and direction what the huge amount of OSS talent could accomplish?

    Interoperability. Most applications are one-off programs made with no thought or care as to how it fits in the bigger picture. Unification, interoperability, and consistency are very important.

    Fleeting Nature. Projects worked on while in college, hosted on random servers, work/girlfriends/distractions. These all can bring even successful and popular projects down overnight.

    What needs to happen is to work under a single focus to create the most perfect distribution possible with clearly defined goals and concepts. Democracy, choice, and chaos have their place and they can be utilized still... just with some oversight and management before it goes live. Once there is a very good foundation (such as how OS X is now) then folks can branch out and work on their own projects and offshoots. I'm not suggesting that all choice needs to be eradicated, just that instead of trying to build a million individual sandcastles on a foundation of Jell-o we could be building a mansion on a sheet of bedrock.

    The talent is here, the passion is here, the momentum is here... the oversight and direction is not.
  • Microkernel (Score:1, Offtopic)

    by zymano (581466) on Monday July 02, @02:16PM (#19720789)
    minix.
  • Isn't this problem only going to get worse? The architecture of bolting everything into the kernel (as a loadable module or not) will eventually collapse under its own weight.

    I can only imagine the mutex nightmares Linux will have when 64 cores become the standard.

    At what point do you sacrifice percentage points of performance for huge savings in complexity and huge increases in stability and maintainability?

    I'd put my money on a microkernel revival in the near future.

  • Natural Evolution (Score:2)

    by tji (74570) on Monday July 02, @04:50PM (#19722601)
    In commercial software companies I've worked for, this sort of thing is typical. But, that structure is quite different from open source.

    Once the product / project grows, the early gurus are needed to lead the direction of the larger group of developers brought in as the company expands. The new guys don't have the understanding of the big picture, so they focus on a specific area, and the best of them bubble up as they get more experience.

    In open source, you don't have the same strict reporting relationship, where the leader can order people to go do X,Y,Z. So, the dynamic is a bit different in the Linux kernel model. There is seems to be more of a review process. The guys at the top of that heap are making sure the right things get included in the kernel.
  • by John Jamieson (890438) on Monday July 02, @11:28PM (#19726559)
    Cmon, instead of spending your time with well thought out reasons as to why the posting is wrong, spend the time gaining control of /. We are the customer, generating the revenue, and we have to keep putting up with this kind of crap?

    When you see a post with the name TACO on it, you automatically know there is a 70%(I guessed) chance it is taking at least a subtle jab at Linux or pushing Apple.

    Where is the feature to moderate the Taco and Gang? (some are better than others)

  • Re:Should have used Eiffel (Score:3, Interesting)

    by ajs318 (655362) <sd_resp2&earthshod,co,uk> on Monday July 02, @11:06AM (#19718441)
    Eiffel? No, they wanted something that would actually run.

    That's why people still use languages like C. It's quick to get a program together, even if it doesn't do exactly what you wanted first time. You fix the mistakes and try again. Each time you go around the loop, there should be fewer bugs (but Sod's Law says that each one will take longer to find). After just a few generations, you end up with a mostly-usable program.

    With all these fancy-arsed "designed so mistakes are impossible" languages, you can spend longer trying to write a "demonstrably-correct-first-time" program than you would chasing down bugs in a nearly-right one. Or at least, that's what it feels like.
    [ Parent ]
  • Re:Should have used Eiffel (Score:4, Insightful)

    by Fujisawa Sensei (207127) on Monday July 02, @11:26AM (#19718735)

    Perhaps you need to get a little deeper into kernel development to find out why Eiffel is a bad choice:

    • Exceptions in kernel space suck. You can look through AROS ML archives for an example of this.
    • In kernel space you don't have access to the standard C libraries, malloc() for instance.
    • Not only don't you have access to standard C functions, you don't want your memory managed for you, that's the kernel's job.

    In summary languages that do stuff for you behind the scenes suck for kernel development.

    [ Parent ]
  • Oh, please (Score:2)

    by WindBourne (631190) on Monday July 02, @11:38AM (#19718885)
    (Last Journal: Friday December 01 2006, @10:51AM)
    what is the link to your OS that is based on eiffel? I can not seem to google, yahoo, msn, dogpile, or anything to find it.
    [ Parent ]
  • If you had happened to read even a couple of comments posted before yours here (or thought about it for a while or RTFA or something else unthinkable), you might have found out that they aren't coding because someone else is doing the coding and the big names are spending all their time managing those coders.

    Your evidence seems to have lost its compass.

    [ Parent ]
  • by setagllib (753300) on Monday July 02, @07:51PM (#19724365)
    What? Okay, so C doesn't have built-in DbC, but it is trivial to add with macros and in fact has been done in every open Unix for many years. FreeBSD and Linux even have invariants for mutex usage correctness and detecting deadlocks, something that Eiffel cannot express without doing a lot more hackery than you would have to with C.

    In my frequent Java work I get by just fine with its DbC, that is its type system, Eclipse' static analysis, 'final' keyword, and assertions. I can't remember the last time I had a non-trivial bug.

    When I was forced into Eiffel work in uni, bugs were aplenty because of the braindead design of the base library, and extremely low-level language constructs. It doesn't even have any 'for' for chrissakes, you have to do a complete from..until..do..end, and manage things like iterators manually. I had to build higher and higher abstractions manually just to make at least some level of source moderately clean, even though I was repeating what should be the compiler's work. Java isn't *much* better in that regard, but still better, and with a lot more machine assistance from good IDEs.

    I'm not saying C is a fantastic language, but it's the best-suited to the kind of work they're doing. There have been dozens of supposed C-killers, and no kernel devs have taken them up with any notable interest. And they're the ones really aching for a more expressive language, so they would know one when they see one.
    [ Parent ]
    • 1 reply beneath your current threshold.
  • Re:Time for a.. (Score:1)

    by Hucko (998827) on Monday July 02, @08:33PM (#19724875)
    http://www.reactos.org/en/index.html [reactos.org]

    there you go.
    [ Parent ]
  • 11 replies beneath your current threshold.