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."
Will? (Score:5, Informative)
Re:Git (Score:5, Informative)
Re:Book needed (Score:5, Informative)
Re:Will? (Score:1, Informative)
Re:Should have used Eiffel (Score:4, Informative)
You're right, you wouldn't. People who spell it the modern way, Lisp, however, would [wikipedia.org].
Re:Fundamental Flaws (Score:3, Informative)
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.
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)
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.
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.
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.