Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming Software Linux IT Technology

Top Linux Developers Losing the Will To Code? 170

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.

Top Linux Developers Losing the Will To Code?

Comments Filter:
  • Will? (Score:5, Informative)

    by truthsearch ( 249536 ) on Monday July 02, 2007 @11:26AM (#19717855) Homepage Journal
    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:Git (Score:5, Informative)

    by CarpetShark ( 865376 ) on Monday July 02, 2007 @11: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.
  • Re:Book needed (Score:5, Informative)

    by fattmatt ( 1042156 ) on Monday July 02, 2007 @11:42AM (#19718075)
  • Re:Will? (Score:1, Informative)

    by Anonymous Coward on Monday July 02, 2007 @12:59PM (#19719157)
    Don Marti did not use the phrase "will to code" anywhere in his article. An editor at computerworlduk.com probably made up that title; it probably wasn't Don Marti, he just wrote the article.
  • by ari_j ( 90255 ) on Monday July 02, 2007 @02:36PM (#19720299)

    You wouldn't write a kernel in LISP on top of bare commodity hardware though.

    You're right, you wouldn't. People who spell it the modern way, Lisp, however, would [wikipedia.org].

  • Re:Fundamental Flaws (Score:3, Informative)

    by swillden ( 191260 ) * <shawn-ds@willden.org> on Monday July 02, 2007 @03:57PM (#19721329) Journal

    OS X. In ten years or so a fairly small team has taken BSD and turned it into what it is.

    More like 20 years. OS X is NeXTstep [wikipedia.org] with a facelift and a few years of minor revisions. NeXTstep development began in 1986 and the first release was in 1989. Not only that, but a typical Linux disto is significantly larger than OS X, since it includes a large variety of applications that Apple doesn't include in OS X, and many of which Apple doesn't even make.

    The pace of Linux development is phenomenally fast, in spite of (or perhaps because of?) all of the false starts and dead projects.

    Imagine with the same focus and direction what the huge amount of OSS talent could accomplish?

    With focus and direction, the OSS talent would accomplish far less. When people are working on stuff for fun, they don't like to be told what to do.

  • Re:Fundamental Flaws (Score:3, Informative)

    by swillden ( 191260 ) * <shawn-ds@willden.org> on Tuesday July 03, 2007 @12:13PM (#19731869) Journal

    also want to have "fun" and working on something cool when I write OSS code... but that doesn't mean I can't be working inside of some sort of high-level constraint or with some design/integration in mind

    The only issue I have with this is that it implies that OSS programmers typically aren't working with some overarching design in mind, and that simply isn't true. Spend some time on project mailing lists looking at how many patches get rejected because they don't fit within the architecture and development approach. Successful OSS projects have a ruthless focus on maintainability, which absolutely requires consistent application of well-defined architectural constraints.

    I'm saying there needs to be visionaries with a full view of the big picture and then it actually makes it easier for everyone else from there down.

    People are certainly welcome to try to contribute however they like, but I'll tell you that in my experience pure visionaries are and will be ignored and, IMO, that's a good thing. Even in the corporate world I really dislike "pure" architects, and I've seen countless projects that have been destroyed by them and their cluelessness. Architecture is crucial, but it works best when the architect also implements [rcn.com]. I'm an architect, by the way, and a big believer in structure, in having a clear, consistent vision of the desired outcome and in having a person who has the authority to make that vision stick. But that person must also be in the trenches and understand how to work a shovel.

    Within the OSS world, credibility is established by producing functional, tight, bug-free, maintainable code. Visionaries who want to give others the big picture have to first establish themselves as people worth listening to. And that's a good thing, because there are always huge numbers of pure visionaries with conflicting ideas pushing any high-profile project. Even if the developers wanted to listen to them, doing so would ensure that nothing of substance ever got done.

    Linux needs more management and it needs more artists/designers, there are talented folks in these areas who are willing to work just as hard as the coders, and yes, even for free.

    Artists and designers, absolutely. UI design is important, difficult work that most programmers aren't very good at, and most OSS developers are perfectly aware that they can use all the help they can get in that department. Management... no. Not from managers who haven't proved themselves as able developers first, anyway.

    Look at the Linux kernel as an example. It is a very well-managed project, and the leaders don't at this point write very much code at all, because they're too busy managing (which is the topic of TFA). Notice, though, that they became managers/architects by first obtaining the respect of other developers by producing good code. Now that they are leaders, they lead in a way that is very different from the norm in the corporate world. They lead not by telling people what to do, but by giving guidelines for acceptability. Linus will reject patches that violate tenets of the overall architecture -- if you want to get your code into the kernel, you have to produce something that is acceptable to him. Further, OSS managers have to logically justify all of their positions, they can never just state them and enforce them by fiat. That doesn't mean they have to convince everyone, but they have to convince enough people.

    The bottom line, for me, is that what you seem to want simply isn't going to happen. OSS developers aren't going to listen to you just because you say they should. If you can find a way to earn their respect, then maybe they will, and the most direct way to accomplish that is to write a lot of good code. If you can't do that, and you don't have any other way to convince people that you're worth listening to, they won't listen to you. Sorry.

After an instrument has been assembled, extra components will be found on the bench.

Working...