Top Linux Developers Losing the Will To Code?

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

Comments

This is Bad?

[Rachel Lucid]

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

Re:This is Bad?

[houghi]

I would say it is the other way around. The higher you get up, the lesser you code.

I also do not see this as a bad thing. One good coder with manager skills or manager with coding skills can be more productive when he manages people.

will has nothing to do with it

[Anonymous Coward]

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?

[brunascle]

that's odd. the linux.com article 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.

Will?

[truthsearch]

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

[CarpetShark]

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.

The Mythical Man Month

[$RANDOMLUSER]

Described this in 1975. As you add more people to a project, communication takes up more time than coding. From Wikipedia:

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

[flaming-opus]

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.

I think the question is more ...

[khasim]

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

Re:Book needed

[fattmatt]

http://lwn.net/Kernel/LDD3/

Re:Book needed

[MROD]

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

Re:Not loosing the will

[All Names Have Been]

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.

I'm loosing the will to spell.

Re:Git

[Dan Ost]

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?

Getting older and coding

[mckyj57]

Programmer burnout is a well-known, if not well understood, phenomenon.

As far as older, I don't think age has much to do with burnout. I started a major open-source project after the age of 40, my first big programming project after a career change. (I am one of the few managers that then became a coder.)

I am now pretty burned out. It isn't that I can't write code -- in fact, I am better than ever. I just don't *want* to write code any more.

Re:Getting older and coding

[mrdarreng]

I just don't *want* to write code any more.

I feel your pain, brother! I've spent my entire career not wanting to write code. Thankfully, I took a dev position at SCO.

Fundamental Flaws

[rAiNsT0rm]

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.