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.

Re:This is Bad?

[Lockejaw]

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.

Exactly. It's a lot like comparative advantage, applied to labor.

Re:This is Bad?

[jellomizer]

Well yes. If you are managing people you have less time programming. At my work I have been taking more of a management role. Having to manage all the accounts take a significant amount of time during the day. So I could spend all days managing people (and working quite hard all day) without writing a single line of code. Secondly as you get older management is more desirable as a career change. I can't speak for everyone, but when I was younger I wanted to prove myself writing good software was exciting because I was able to expand myself and create code that people enjoyed. But as time goes on, coding has became more mundane, you get less complicated problems as your skill increase. Management allows you to exsersise other areas of your brain and you can use your talants to help more Jr. Programmers increase their skills, or as sanity check for Sr. programmers.

Re:This is Bad?

[pagen_hd]

Slashdot is a good reason why nerds are better than managers. Don't feel bad. You can lose the will to code, but don't ever lose the will to play games! I've heard that some programmers got rich and moved to a remote island -- without video games! Com'on, at least bring Far Cry! Ok, don't go off-topic.

Should have used Eiffel

[Meor]

This is what happens when you write large procedural code programs with no Design by Contract. You spend more time rechecking old things than writing new things.

Re:Should have used Eiffel

[ajs318]

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.

Re:Should have used Eiffel

[Fujisawa Sensei]

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.

Re:Should have used Eiffel

[Anonymous Coward]

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

Yeah. Those LISP machines, they were really terrible.</sarcasm>

Re:Should have used Eiffel

[Anonymous Coward]

LISP machine kernel didn't have to worry about virtual memory management.

Re:Should have used Eiffel

[Anonymous Coward]

LISP machines are a special case: the hardware was built specifically to run LISP well, and implicitly supported the sorts of magic LISP expects. You wouldn't write a kernel in LISP on top of bare commodity hardware though.

Re:Should have used Eiffel

[ari_j]

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.

Re:Should have used Eiffel

[kdemetter]

that doesn't have anything to do with the programming language itself , but with the steps before the actual programming ( wich is to often neglected ) . sorry , but your model ( build & repair ) won't work very well . The key is complete analysis of the problem , knowing what you want to create and how the application will be build up ( see the Waterfall model ) . that will be more likely to lead to a succesfull program . to get back on the subject , this is problably what those senior programmers will be doing if they stop coding . They have better insight in what is possible , and more patience than younger , more passionate programmers :-)

Re:Should have used Eiffel

[WilliamSChips]

Notice which modern languages are the ones that are taking off. Python and Ruby, primarily. Both use the REPL technique which allows software to be developed much quicker.

Re:Should have used Eiffel

[Meor]

Development is a very small part of time invested in a project, you're trying to optimize the already fast part of the development cycle. I've never heard of the term REPL before. Can you explain how this is different than a step-through debugger? Python and Ruby? More like PHP and C#.

Re:Should have used Eiffel

[setagllib]

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.

Re:Should have used Eiffel

[Meor]

* Do you mean exceptions as in the programming construct or hardware/software exceptions as in program halt, segment push, address push, load IDT selector, call exception handler? Unhandled exception as a programming construct means a kernel bug, unhandled hardware exceptions are always a program in kernel development and have no bearing on the language being used.
* More specifically you don't have access to sbrk() or HeapAlloc(). The first thing all kernel programmers do is implement sbrk() and malloc() so I did know that already, thanks.
* No, most kernel programmers are perfectly happy with using existing implementations of malloc(). The hard part related to memory is handling page faults and doing disk paging. The true hard part in kernel development is getting hardware companies to release their specifications so you can write drivers for it.

In summary, how did that post get moded up +4 insightful? It was completely inaccurate and retarded.

Re:Should have used Eiffel

[Meor]

The original post was mostly tongue in cheek but it's interesting what comments it draws.

I'd like to see how you ensure the (int) member of a structure always has a value between 1 and 10 in the face of a new programmer modifying the source code and doesn't know that it in fact needs to be between those values. You could make all other code have precondition contracts but that doesn't specify who set the member wrong in the first place. If the bug isn't found for a long time, you'll be hunting forever trying to catch something real DbC would have found in milliseconds. You could say "comment the code" but empirically as code changes, the comment don't get updated, even if there were comments in the first place.

Checking correct mutex usage is simple, enforce a total ordering on all mutex lock acquires. Eiffel could do that very easily, I don't know where you get the idea it can't. Knowing the system is deadlocked is different than being able to do something about it. Mutex deadlock would mean a kernel panic or killing of the offending processes in order to 'solve' the problem.

Explain again how a for loop is different than a from loop? for(i = 10; i >= 0; i--) from i:= 0 until i=10 loop i:=i+1 end But back to DbC, with Eiffel you could put in a loop invariant to make sure your loop is always one step closer to completing, something you can't implement in C without a lot of hackery, but then again, C programmers love hacking.

True, C is probably still the best language for kernel development.

Re:Should have used Eiffel

[WilliamSChips]

Read-Eval-Print Loop. It's a Lisp term, it basically means when you run python or ruby in a console you get this screen where you can try out commands and such. It really helps.

Re:Should have used Eiffel

[ajs318]

The key is complete analysis of the problem , knowing what you want to create and how the application will be build up ( see the Waterfall model ) . that will be more likely to lead to a succesfull program .

Then you run afoul of Mitchell's Law of Committees, which states that:

Any simple task can be declared impossible if enough meetings are held to discuss it.

This appears to be an incorrigible problem with human nature and is not unrelated to the fact that it is easier to obtain forgiveness than permission. People are fearful of the unknown. If you do actually dive in and produce something, even if it's not exactly right, at least it's not unknown anymore -- therefore it's less scary.

Everything in real life that actually works well follows the classic biker's model of "try it, saw a bit off here, weld a bit on there and try it again". Meanwhile in meeting rooms all over the world, people are arguing over the merits of things that aren't actually happening because they're still being discussed.

Re:Should have used Eiffel

[TheLink]

Python and Ruby?

But PHP seems awfully popular. Or should I say terribly popular?

I can't decide... ;).

Re:Should have used Eiffel

[Anonymous Coward]

In fact, it was quite common to use minimal dialects of Lisp as a systems programming language in the 1980s and 1990s -- Pure Lisp (Cartwright and McCarthy, 1978) forms the basis for most of these.

More generally, the only trick to using ANY Lisp-like language for systems programming is being able to explicitly allocate and deallocate pools of memory not managed by the garbage collector, and to explicitly perform object create, destroy, slide, import and export operations in those pools.

unwind-protect and dynamic-wind systems were generally sufficient for managing transient objects in unmanaged memory, although weak pointers were also sometimes used.

In general, none of this posed much problem for compiler writers, and the careful selection of a hygeinic macro system for abstracting away management of objects from outside the GC arena also posed little difficulty.

Apart from the fact several solid Lisp environments (commercial and otherwise) have been ported to almost every major operating system in current use, and the evolution of ffi/POSIX calls as a de facto standard part of Lisp programming, the major stumbling block is that almost no modern microprocessors make it easy to accurately identify a pointer. As a result, some software tagging and boxing will be necessary, which will slow down operations on the affected datatypes (usually integers are robbed of one or two bits which are used to distinguish between integer data and memory addresses). Alternative, conservative collection could be used, imposing other costs, and running the risk of memory leaks.

The CADR processor design and its relatives were not as heavily specialized for Lisp as you'd think; the major unusual features were pointer-tagging (and tagging of other native data types), tag-based data-type-testing, rapid selecting of the correct specialized branch of an overloaded instruction, list compactification ("CDR coding"), the incremental garbage collector, and on-chip support for the function calling convention (lambda lists).

The arrival of RISC-ish ISAs with many registers allowing for fast register-to-register shift/rotate/mask-and-match operations, improvements in compiler design especially with respect to Data Flow Analysis after the Yale T project, and the development of background-thread generational garbage collection, generally eliminated most of the runtime advantages of CADR-type hardware support.

x86-64 is reasonably tolerable, as evidenced by the openmcl port in particular, and one could certainly use the output of its compiler for doing "bare metal" systems programming, including OS development.

It was pretty easy to find this page full of links to various experimental and prototype OSes involving Lisp and Lisp-like languages running on bare metal. Sadly there is some link rot, and a substantial number of abandoned projects.

Re:Should have used Eiffel

[Anonymous Coward]

From http://en.wikipedia.org/wiki/Visual_C++:

The "edit and continue" functionality allows changing the source code and rebuilding the program during program debugging, without restarting the debugged program.

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"

Re:will has nothing to do with it

[Anonymous Coward]

Shouldn't there be better way? Those who are talented in managing (and presumably not so in coding) gets promoted as managers, those who excel at coding gets to work on challenging stuff. Why take top coders and make them managers? It seems corporate ways have infected open source developers: keep promoting the talented up to a position where they are least qualified and let them stuck there.

Re:will has nothing to do with it

[Torvaun]

Yeah, have people who are talented coders get promoted to designers or code supervisors. Actually writing code can easily be a generic position, easily swappable (assuming company coding standards). Code design, writing the pseudocode or flowchart or whatever to define the steps code must take to be functional, that's the stuff for coders who can think of a task in the same way a computer does. Code supervising would then be the review of code being produced by the low level code monkeys. This kind of promotion goes to the coders who are also good proofreaders, the ones that have a knack for spotting inefficiencies and unintended features (bugs). Those are the difficult parts of coding.

Re:will has nothing to do with it

[sick_soul]

> Actually writing code can easily be a generic position,
> easily swappable

This is what most companies get wrong.
Coders are not easily swappable, no matter how much policy
you try to set up: the differences in skill have a
tremendous impact on the quality of the code, and if a
more talented supervisor must always veto/fix the code of its
underlings, it is a waste of time for everyone involved.

Only good coders should work on the code base in any position.

Those who also show management skills should get burdened by
the additional task of actually managing people and
distributing work, and they will slowly code less and less,
while the good coders which do not show management skills
should just code on.

Re:will has nothing to do with it

[Anonymous Coward]

Even a little stronger than 'I haven't time to code", it's "I don't GET to code anymore."

I'm in the a similar boat in a medical imaging enterprise. I don't get to do much coding since I spend most of my time figuring out the meta-how to get solutions for internal customers. Occasionally that means I get to roll up the sleeves and crack out the editor, but mostly it means farming tasks out to the worker bees and balancing bee capacity against customer desires. If life were as simple as just writing code it would be easy (but there is a quid pro quo --- if you want more pay than a worker bee you have to leverage the work of the worker bee).

Re:will has nothing to do with it

[setagllib]

It's not that simple though. Linux needs a next generation of good coders, and tomorrow's good coders are pretty bad today. If their skills can be cultivated in the educational environment of Linux development, they'll stick with the project and eventually become good or even really good. If they'll never become really good, it'll probably show up as evidence too early to really matter.

It doesn't take a genius coder to implement a driver by a specification, or write then run some tests based on suggestions, but some experience will do. The really brilliant coders are where they belong, designing and implementing schedulers, device driver *architectures*, file systems, and so on. Some of the decent coders will move up to be brilliant. You won't know unless you invite them all in and sort them out later.

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.

Re:a good or bad thing?

[bjourne]

And they do think it is a good thing. Unfortunately, you won't be able to find out without reading TFA. :)

Re:a good or bad thing?

[mr_mischief]

I haven't read TFA yet, but I'm betting some of them think it's a good thing for the project and are willing to do what they're doing, despite the desire to do more coding.

So?

[Actually, I do RTFA]

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?

[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:Will?

[merreborn]

Those mugs are lame. Especially because the string constant 'coffee.php' is unquoted on the PHP mugs.

Re:Will?

[Anonymous Coward]

Notice: Use of undefined constant coffee - assumed 'coffee' Notice: Use of undefined constant php - assumed 'php' Warning: include(coffeephp) [function.include]: failed to open stream: No such file or directory

Re:Will?

[Anonymous Coward]

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.

Re:Will?

[Anonymous Coward]

I think it's appropriate that a PHP mug has an error on it. I think the next one should have a sql injection attack.

Git

[CarpetShark]

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

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

Re:Git

[DogDude]

they just need to learn from Linus.

Actually, I'd say that Linux sounds like a piss-poor manager. With management like this, I'm not surprised that Linux is still playing catch up, 10+ years into it.

Re:Git

[CarpetShark]

Sure, keep telling yourself that, as you PAY THOUSANDS at Microsoft to make an inferior but shiny OS.

Re:Git

[Anonymous Coward]

Or switch to a real OS like *BSD or Mac OS X. Microsoft isn't the only or best alternative to Linux.

Re:Git

[DogDude]

How is that relevant as to whether or not Linus is a decent manager?

C'mon. That was a pretty weak troll.

Re:Git

[WindBourne]

1. linux is an OS, and yes, it makes a lousy manager over ppl (but a good one over hardware resources.
2. Exactly what is Linux is playing catch up on?
3. And I am guessing that you think Linus is a poor manager. What do you base that on?

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?

Re:Git

[CarpetShark]

Ermm... the same way that your entirely baseless accusation of Linux "playing catch-up", and LinuS being a bad manager is related to whether Git is a good solution to an entirely new situation? (Hint: microsoft don't have any of the new situations to deal with that a large open source project has, and they still had to cut back on most of Vista's features, before most of the critics calling their project a failure)

Re:Git

[CarpetShark]

OS X seemed like a good idea once. I even bought an iBook for that. After actually trying to get a decent workflow setup on it, my iBook runs KDE now :)

Re:Git

[CarpetShark]

Oh, and no FreeBSD newer than 4.x will even boot on my x86 box, which runs other OS's just fine. I agree that *some* things are done better in the *BSDs though.

Re:Git

[Anonymous Coward]

Ermm... the same way that your entirely baseless accusation of Linux "playing catch-up"

If you think GP actually knows anything about Linux, maybe this will clear up that misconception.

Re:Git

[Anonymous Coward]

Uh-oh, DogDuty is back. Should'nt you be selling some doggy bags or (failing at) banging some fat chick somewhere? What the fuck are you doing posting on slashdot you limpdick?

It's just maturation: projects evolve

[postbigbang]

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.

Everyone can help in some way.

[Dareth]

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.

Re:Everyone can help in some way.

[Anonymous Coward]

I would even dare say the "Grammar Nazi" who helps correct documentation helps too.

You're missing a comma before "too".

Re:Everyone can help in some way.

[ajs318]

Not necessarily. There are two schools of punctuation: one, which believes in including a punctuation mark -- a dash, a comma, a semicolon or a colon -- at any point in a sentence where a pause, or a change of inflection, might reasonably be indicated; and the other which believes that unnecessary punctuation marks serve only to clutter up sentences and reduce visibility.

Re:Everyone can help in some way.

[Anonymous Coward]

There are three schools of thought on punctuation. You mentioned two of them. The third subscribes to the idea that punctuation should be used to indicate grammatical structure. This school is correct. The meaning of a sentence can change unless this structure is marked.

A canonical example: "The panda eats shoots and leaves" versus "The panda eats, shoots, and leaves."

Re:Everyone can help in some way.

[ajs318]

Not quite.

In spoken English, pitch, loudness and timing are all used to indicate grammatical structure. Notice how your voice rises in pitch at the end of a sentence when you ask a question? Yet it falls when you make a statement. And everyone knows that writing in all capitals is SHOUTING! (I once told someone who was a bit ignorant about technical matters that sending text messages in all capitals would drain her phone's battery more quickly. She believed me -- for just long enough to get into the habit of not using caps all the time.) English seems to bounce along with alternating stressed and unstressed syllables (you need to say that one out loud). We introduce pauses to separate items in a list, to separate thoughts or just for effect.

Punctuation marks are just a way of conveying all these subtleties in writing. Spoken out loud, your sentences would sound like "The panda eats shoots and leaves" (slight emphasis on "shoots" because it's first in a list, and probably a euphonic "r" sound inserted between "panda" and "eats" to break up the pair of vowel sounds) and "The panda eats ........ shoots ..... and leaves" (with no euphonic "r", instead a glottal stop [imagine someone saying "glottal stop" in a Cockney accent -- that's what the sound you heard in place of the T's is called] and emphasis on "eats", and pauses where indicated by thought marks). If you meant to indicate that the black-and-white bear engaged in a spot of post-prandial target practice, then you would write a comma after "eats" to indicate the pause there (there's no need for one after "shoots" because it is the last-but-one item in a list and so followed by "and" or "or", which do not usually require a preceding comma.) There are also techniques for conveying inflection by displaying animated text, but these are of limited value since they can't be printed.

Over-punctuation is a tendency to indicate every subtle nuance of the spoken language, even the ones which could be inferred. It tends to look rather old-fashioned. Modern practice is generally only to indicate the most important ones (and I agree, in your panda example, the meaning of the sentence depends on the punctuation). Another example is the publican's request to his signwriter: "We need more space between Wagon and and and and and Horses" which really requires at least a comma (We need more space between Wagon and and, and and and Horses) but would look better with either speech marks ("We need more space between 'Wagon' and 'and' and 'and' and 'Horses'") or (if available in the medium) some form of visible emphasis ("We need more space between Wagon and and, and and and Horses"). Note that this breaks the rule about not putting a comma before "and"; but this is merely an invocation of The Last Rule, which states "Anytime you have to break any of the preceding rules, make sure you break 'em good and hard." (Closing full stop inside speech marks in this case, because it belongs to the text being quoted).

Good news

[Anonymous Coward]

America's Urban Black Population Falls Dramatically
As Many As One Tenth Of Black Population Dead Over Past Five Years

6/30/2007 10:49:41 AM
Discuss this story in the forum
Overthrow Staff

Washington, DC -- A new report, cited in the Economist magazine, indicates America's black population has fallen dramatically over the past five years, despite Census bureau estimates and demographic doomsayers' prediction of growth that would overwhelm whites.

In America's three largest cities -- New York, Los Angeles, and Chicago -- black populations dropped by one tenth due to the cumulative effects of murder and disease.

Discussing "the disappearance of blacks", the Economist writes, "Roughly half of America's murder victims and about the same proportion of suspected murderers are black. In five years America's three biggest cities lost almost a tenth of their black residents ..."

One tenth of America's black population -- over 3.8 million Negroes -- lived in those three cities, and the disappearance of 380,000 of them due to AIDS, murder and other causes represents a one percent decline in America's overall black population.

The trend is similar to that in Africa, where nations such as South Africa have seen AIDS and crime cause their national population to begin falling at a rate of one half to one percent a year, and where acts of war and genocide -- Negro crime taken to an exponential level -- have destroyed a tenth or more of the population of central African nations every several years.

-----

Published by:

Overthrow.com / White Politics, LLC
ATTN: Bill White, Editor

Post Office Box 8601
Roanoke, VA 24014

http://www.overthrow.com/
nationalsocialistworkers@yahoo.com

Re:Good news

[Anonymous Coward]

I know its feeding the trolls, but its been a while, and trolls need to eat too..............

The census is correct, minority numbers are growing... There are fewer of them in the urban areas perhaps, but there are a LOT more in the suburbs. Its a slow uphill march, but situations do improve for some members of minorities, and its amazing that the fact that a percentage have managed to "improve" their situation enough to move out of crime ridden urban centers can somehow be twisted into a negative statement about them.

Not loosing the will

[realdodgeman]

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.

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:Not loosing the will

[realdodgeman]

I'm loosing the will to spell. Keep commenting like that. I am not English, and this is the only way I can learn it. Anyway, it is not like I have anything to loose...

Re:Not loosing the will

[smellotron]

I'm loosing the will to spell.

Keep commenting like that. I am not English, and this is the only way I can learn it. Anyway, it is not like I have anything to loose...

Kudos for multilingualism. The grandparent may have commented with the assumption that English is your native language, so don't take the jab too heavily. However, don't dismiss it. If Slashdot is a forum that helps you learn a language, consider it a lesson learned that "loose" is different from "lose". In fact, you do stand to lose from poor spelling; on a forum where your entire character is based on your text, you will (for better or worse) be judged on the quality of that text.

Re:Not loosing the will

[realdodgeman]

Ok, I tried to make a loose/lose joke when I replied there, but it might be hard to understand, since I first explain why I spelled wrong.

Anyway, it is not like I have anything to loose... That one was a joke.

Re:Not loosing the will

[TheLink]

Don't learn English from Slashdot! It's pretty bad here.

Try the following instead:
http://www.newscientist.com/news.ns

http://www.economist.com/science/tq/

Time for a..

[Anonymous Coward]

Fork.

Re:Time for a..

[Hucko]

http://www.reactos.org/en/index.html

there you go.

Re:Time for a..

[Hucko]

oops wrong thread. sorry.

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.

Re:The Mythical Man Month

[Anonymous Coward]

> (without a hierarchy)

Since linux has a "web of trust" (==explicit hierarchy) your post becomes largely irrelevant. Also, the MMM is talking about a situation where the new programmers have to be trained. One interesting thing about Linux programming is that the experts don't "have to" train the newcomers. They are allowed to ignore them. Now, I'm not saying that the MMM doesn't have many truths which could apply here, but we applying them in such a new situation is very difficult and needs a little more careful analysis.

Re:The Mythical Man Month

[CoughDropAddict]

That's exactly why it's totally ridiculous that it is contained in a single source repository!

Need a newer version of the USB subsystem, or a fix to a driver? Have fun downloading a new version of Linux, which has an ungodly number of changes across the entire kernel.

People tend to think of monolithic/micro kernel only in terms of run-time technical advantages/disadvantages. But equally important IMO is the impact on development processes. With a good microkernel architecture, it would be totally reasonable to think that you could upgrade an entire subsystem (like USB) without touching the rest of the OS. Each subsystem could be run as an independent project with its own releases, and there could be competition for who can make the best subsystem.

Re:The Mythical Man Month

[eMbry00s]

This is only true when you have code depending on other code, and thus people needing to communicate with others. Open source software obviously does not suffer from this as Linux's thousands of contributors do not need to communicate with all of each other. Re-read the Cathedral and the Bazaar.

Re:The Mythical Man Month

[Anonymous Coward]

They aren't *actually* independent. There are a lot of inter-dependencies there; core functions and structures change often, and to accomplish something like that you'd need the added complexity of some dependency checker/updater and expect end-users to be able to operate it. On the other hand, if you're looking for one fix to a particular driver, just search the mailing list. Patches are posted regularly in an accessible format with great descriptions and discussion.

Re:The Mythical Man Month

[timeOday]

What you describe isn't unusual within Linux at all. If you have a problem with a module, you can often visit a developer's page, and fairly often get a later version of the driver which is still compatible with the kernel version you're running (e.g. IVTV). Then you either patch your kernel tree or compile the modules outside the kernel tree (for instance the pcmcia subsystem) and load it in. As for competing subsystems, think about oss vs alsa, or ipfwadm vs ipchains vs iptables, or udev vs devfs. It's just that all this is usually left to distro maintainers, because most people don't care. Maybe what you think you want is rock-steady kernel interfaces so a given driver is compatible with more versions of the kernel - but then you can kiss progress goodbye. I think Linux has it right: support the current way of doing things, plus the outmoded way of doing the same thing for a year or two, then get rid of it. Otherwise you're going to replicate the 20 year transition period it took Microsoft to get from DOS to XP.

Re:The Mythical Man Month

[Omnifarious]

That's a really excellent book on software engineering. One of the best ever written. And while I think that formula is fairly accurate I also think there have been advances in techniques for writing software that allow you to get away with much thinner communications channels in many cases.

For example, someone here mentioned that the kernel was really several different largely independent software projects. And while I think this is something of an oversimplification, I also think it's true.

As another example or idea... I've noticed that relational databases (though I think (being a ReiserFS fan) that they are slightly evil) allow many developers to code to the database spec without having to talk to eachother that much. As long as the database schema is designed well and documented a bit you can count on it not changing radically and base your code around it. This greatly reduces communications overhead.

Re:The Mythical Man Month

[Lars512]

It also assumes that no hierarchy is being used. Clearly there is a management hierarchy for the Linux kernel, with Linus at the top. He's not communicating with every developer directly, nor should he. What The Mythical Man Month is saying is that a project with this many developers would be infeasible without a large hierarchy supporting the bottom level developers. So this story is just: more developers, more management. What a surprise, hey?

Book needed

[jshriverWVU]

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

[fattmatt]

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

Re:Book needed

[jshriverWVU]

Sweet! and it's under a creative commons license so you can download it as a pdf. Though if it is as good as it seems I'll definately support it by buying the pulp version. Thanks for the link.

Re:Book needed

[holden caufield]

There really needs to be a howto or book on how to write a linux device driver.
You mean like http://www.oreilly.com/catalog/linuxdrive3/?

Re:Book needed

[Anonymous Coward]

+5 informative

Re:Book needed

[quanticle]

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"

Just a little searching on Google and Amazon netted me the following two titles:

• Understanding the Linux Kernel
• The Linux Kernel in a Nutshell

The resources for understanding the Linux kernel are out there, you just have to have the motivation and interest to look for them.

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:Book needed

[Hognoxious]

Is something like this what you mean?

Re:Book needed

[Triddle]

If you need a book then I don't really want you messing with my kernel. I'm a C programmer with 20+ years experience, but while I am good at what I do I am not as knowledgeable as those guys so I don't get in their way. I'd like to, very much, but the Linux kernel is beyond the level at which I can contribute in a meaningful way. If you think you can do so without knowing exactly what you are doing, then I admire your will to help but please, wait until you *know* your contributions will cause less work than you put into them.

Where you may be able to provide real assistance is in the documentation. All coders hate documentation, but it still needs to be done.

Re:Book needed

[janrinok]

Thank you. I've nothing constructive to add to the discussion but I felt that your efforts needed acknowledgement!

Re:Book needed

[bfields]

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.

Nah. A lot of the basic stuff stays the same. And time invested in something that's changed isn't wasted time--an understanding of the old interface will probably help learn the new one. And I'll second the recommendation for the "Linux Device Drivers" book, it's good. See also lwn.net's kernel section for updates to the various api's.

Simple, separate the core kernel from the drivers and produce a specification for the interface which only changes with the major kernel version.

Fine. Try it. What I think you'll find is that just identifying which interfaces drivers need is a huge job in itself. Then you'll have to figure out how to maintain them when bugs are discovered or new features are needed. (If you suddenly discover that widgets can be hotplugged, and that your current widget api assumes the set of widgets available never change, are you going to add an entirely new widget api, and then maintain both the new and the old one? That doesn't sound simpler! Or are you going to make users wait a development cycle before they can plug their widgets in?)

rather than management seeing the driver maintenance and support costs being too high to bother because of the constant code churn.

The cost for in-tree drivers isn't that high--whoever fixes the api also fixes its callers in the drivers. Out-of-tree drivers have it harder, yup. So don't do that.

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

Who said that? Drivers are written by people with expertise in and access to the particular hardware--usually not core kernel maintainers. Once written, the work of future maintenance is then shared.

Re:Book needed

[renoX]

>The problem is that with almost every minor kernel version revision the driver interface is changed,

While it's true that driver interface change, usually those change only impacts some drivers not all.

>This is why the current fluid kernel/driver interface specification is unsustainable and unmanageable in the long term

In the *very long term* maybe, but currently the amount of code changed each day is accelerating not slowing, so apparently it's not too painful yet.

In the long term, yes I can the see the interface kernel/driver stabilizing, but not for the reason given but because the kernel itself stabilize, so this will take a long time..

Re:Book needed

[reed]

That sort of sounds like generally accepted software engineering best practices. But that's just in general, and it's not really how Linux works. Linux would suffer if they tried to suddenly and arbitrarily impose such practices that conflict with current practices.

Anyway there is at least one book about Linux device drivers: http://www.oreilly.com/catalog/linuxdrive3

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:I think the question is more ...

[timeOday]

So what happens when these gurus take one more step up the ladder and OSS becomes overburdened with PHB who make life miserable for everybody :)

Re:I think the question is more ...

[zCyl]

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.

Re:I think the question is more ...

[Anonymous Coward]

It implies it, but as we all know from some of the bugs that still keep popping up over and over again, it aint getting checked more times.

Re:I think the question is more ...

[Stormy Dragon]

Actually, increasing checkers often leads to MORE bugs getting through. As you increase inspectors, each individual tends to subconciously get less focused as there's now someone else who can catch things if they miss it.

Is that so bad?

[Anonymous Coward]

Seems to me this is a great way to teach a burgeoning mass of hackers to become better/good kernel hackers, and that is surely a good thing.

An inevitable outcome of growth

[simong]

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

[nuggz]

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.

Not only is this natural but it is also Good

[ThePopeLayton]

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.

Losing the Wii to code...

[Anonymous Coward]

Sadly, this seems to be the trend. Initially, games are produced for the sake of fun and excitement. Yet as of late, game developers certainly seems to be getting lost in other aspects of development, such as coding. I hope this isn't the case for upcoming titles.

Perhaps in writing response to what I want the article to say, I can, in fact, change the content of the article. Or at least humor myself.

GregKH driver tutorial

[ezh]

Here is a tutorial from Greg KH from Ottawa Linux Symposium 2005 (and 2006):
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial/
And sample code for a USB thermometer
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial_example_code.tar.gz

UDEV

[Anonymous Coward]

If that means that Greg can stay away from coding/designing another jewel like UDEV, I see that only as a Good Thing.

this always happens

[SolusSD]

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

[hikerhat]

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.

tr0ll

[Anonymous Coward]

BSD machines, 80s, DARPA saw BSD [gay-sex-access.com]? Oth3r member5 in and as BSD sinks well-known United States of

OMG, u r teh 733t!

[edittard]

If you need a book then I don't really want you messing with my kernel.

Nonesense. Kernel programming is so different from the application side that even for a competent C dude there's a lot to learn - why not benefit from someone else's experience?

Oh, it's probably his kernel he wants to hack around with. I don't have any problems with that, and I don't see why you should.

Re:OMG, u r teh 733t!

[Triddle]

I've done UNIX kernel programming. Have you? Don't comment until you have. I'm a very competant 'C dude' who earns his living writing embedded code. Operating systems are my particular interest, but I know my limits. Don't you dare fuck my kernel up for me. His kernel *is* my kernel. He clearly does not have the knowledge to create his own, whereas I have in the past. For UNIX, LINUX and XENIX. Here's where you get to present some credentials instead of just sprouting bullshit. You move...

Re:OMG, u r teh 733t!

[Anonymous Coward]

There's a difference between programming for you own use and programming for the masses. By definition any [good] changes you make to Linux must be presented for possibkle addition to the codebase. The aforementioned overworked and their minions get to decide if the code is worthy of inclusion in the general release kernel.

It's clear that it is possible for an inexperienced coder to make incorrect changes to the kernel and get them included. That's a big problem. Let them play with their own kernel by all means, but don't touch the publicly avaliable one until they actually know what they are doing.

Re:OMG, u r teh 733t!

[edittard]

I've done UNIX kernel programming. Have you?

No. So what?

Don't comment until you have.

Who died and made you king?

Don't you dare fuck my kernel up for me.

Or you'll do what?

His kernel *is* my kernel.

No it isn't. You're laughable.

Here's where you get to present some credentials instead of just sprouting bullshit.

I'm an astronaut, before that I was a brain surgeon, so yah boo sucks.
P.S. competant, LOL.

Re:OMG, u r teh 733t!

[Dog-Cow]

You are beyond stupid. A newbie coder playing with his copy of the kernel source can do anything he damn well pleases and he doesn't have to present his work to anyone else at all. If he wants to give someone else his copy of the kernel, he has to present his changes in source form as well. But that won't get his code into the mainline tree. The whole point of the code managers which the article discusses is that there is a mechanism in place to keep out bad code. It doesn't matter who writes the bad code; there will be someone reviewing it. Even Linus has his code reviewed, even if there is absolutely nothing but social pressure to keep his own bad code to himself.

Oh, please

[WindBourne]

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.

Where's the beef?

[billsf]

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

Not news, this is normal

[CodeShark]

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.

Antithetical.

[wild_berry]

The kernel developers have decided that black-box/proprietary drivers aren't welcome in their kernel and ask that companies submit their drivers as patches to the existing kernel. That's why 52% of the kernel tree is driver code. It also means that the drivers are free-as-in-GPLv2 and can't be withdrawn later on. If they become abandonware, they are freely available to be updated by a third party. I see these as advantages sufficient to support the present Kernel Development method.

Re:Antithetical.

[MROD]

I didn't actually mention black-box binary-only drivers or even those not released under the GPL, that's a totally separate issue. This is a maintainability issue and the costs to companies to keep modifying their code almost every time there's a minor kernel version change.

If a company can assign programming resources once off for a driver project and not have to spend extra resources every few months just because of a change in the kernel interface then they will look far more kindly on the idea of developing a driver, be it GPL'd or not. Remember, Linux is a small player for the hardware people and hence only minimal budget can be allocated to any driver project. Recurring costs (other than for bug fixes) are a major financial barrier.

Re:Antithetical.

[wild_berry]

I was proposing that the inclusion of a device driver in the mainline kernel tree fixes the maintainability issue: it is updated with the kernel tree.

Re:Antithetical.

[MROD]

Which means that it's more work for the core kernel developers... Which is the whole point of the original posting.

Separate the drivers currently in the kernel source ball out into a separate project and define a kernel/driver programming interface and that work is decreased hugely. The side effect would be that hardware companies would find it far easier to develop and maintain drivers so that their management may actually think it worth the resources they can afford to give it. Again, this has nothing to do with whether the drivers are open, closed, GPL'd or released with any other license or even fully public domain.

Re:Antithetical.

[wild_berry]

Ah. Thanks for explaining that. I guess, were I hard-working enough to read and ACK patchsets for the kernel, I'd say that the interfaces are documented in the /Documentation directory of the source tree and in the C code itself. Writing a standard interface would only be an addition to the /Documentation tree, especially with Corbet/Kroah-Hartman/Rubini ("Linux Device Drivers", O'Reilly) being available at lwn.net (http://lwn.net/Kernel/LDD3/) under the Creative Commons 2.0 Attribution ShareAlike licence. Linux Device Drivers may cover 2.6.10, but any changes to the kernel over the past 18 months/two years are documented also at Linux Weekly News.

Circle of life!

[ceeam]

More appropriate caption would be "Top Linux developers are replaced with new ones as time go by".

Re:Not loosing^H^H^H^H^H^H^H losing the will

[Anonymous Coward]

Losing, not loosing, for the sake of Webster's spinning corpse, you damnable corpse-spinner!

Stop the presses!

[MrZaius]

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.

Will, no. Innovation, yes.

[Anonymous Coward]

Linux is just about finished right now. Just wrap it up and ship it.

Re:Will, no. Innovation, yes.

[cp.tar]

Sure... if it compiles, ship it.

Management is just another form of coding

[Fractal Dice]

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 !

[Marbleless]

Perhaps this is the problem

http://web.archive.org/web/20030620163003/http://d ilbert.com/comics/dilbert/archive/dilbert-20030619 .html

;)

Better Headline

[Anonymous Coward]

Top Linux Developers Using the Wii To Code!

Better management...

[SanityInAnarchy]

Oh, how I wish some of my day job bosses had ever written a single line of code in their lives...

As time goes on, it sounds very similar to

[Anonymous Coward]

Communism. With the communist nations, people got tired of trying to innovate anything or working as they got nothing for it. Where is the drive for anything with communism? This is the biggest reason communism has failed and will always fail. This is why Linux "or open source period" has failed and will always fail.

This isn't meant to troll or flamebait, but the evidence is pointing in that direction.

Re:As time goes on, it sounds very similar to

[Anonymous Coward]

Yep, you are right about one thing. The evidence is pointing towards you being a fucktarded winblowz troll who should go out and commit suicide immediately since you are obviously too fucking stupid to even exist let alone use a computer. Capitalism and religion is what is destroying the world, communism and Freethinking will save it. COMMUNISM, OPEN SOURCE AND ATHEISM FTW!

Re:As time goes on, it sounds very similar to

[Delkster]

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.

Reviews are important

[zdzichu]

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.

Re:Reviews are important

[Anonymous Coward]

> Reiser4fs was stalled so long because there was no person simultanously fluent in filesystem and willing to review its codebase.

It doesn't help that Reiser wrote it in a highly idiosyncratic code style, then when people asked him to code it to the kernel standard, he pitched a hissy fit, accused everyone of conspiring against him, and threatened to take his ball and go home (and more than once, the response was "there's the door", but he never took it).

Wii?

[Monoman]

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

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.

Re:Getting older and coding

[Anonymous Coward]

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

So what *do* you want to do? Serious question because I know someone in a similar position - apparently 'burnt out' re. programming but more like 'not burning for anything'. Hmmm.

Re:Getting older and coding

[phantomfive]

Actually, the problem happens as soon as you stop trying to improve. Once you reach the level where you are satisfied with your skills and no longer try to move to the next level, boredom will set in. The same thing happens in the theater world, where for example phantom of the opera plays every night for 10 years in a row. Don't you think Michael Crawford would get tired of saying, "she is singing to bring down the chandelier!!" year after year? And yet each time he says it, there is the illusion of freshness, that it is the first time it has ever happened. And that is why: because each moment of each performance he is trying to improve. Lessons for life.

Re:Getting older and coding

[rtb61]

Making space, making space, it is all about making space. Open source as an open contributory system reflects the wider community, new fesh blood needs room to work and play, whether they happen to be young or old in terms of years, they are just new at that particular community development project.

Fresh thoughts and fresh minds, those who have been at it for a fair while can sence the eagerness of the newcomers and know they need to shift the contribution to areas where their experience will be of greater import, whilst the agile and quick coding minds can contribute most effectively at the code the more experienced can hone that contribution to a fine art.

A big thing about open open source is publicly demonstrating your coding skills to a peer review audience, as such, that opportunity must be maintained so the upcoming coders can gain the reputation and gain access to a highly rewarding career for those with the best skills. You really do want to avoid old timers hogging all the open coding limelight, but you certainly don't want to lose their experience and in the open source world, their genuine integrity and pride in workmanship.

Re:Getting older and coding

[mwvdlee]

Yeah, you SCO devs are just copying bits of Linux, then blaming Linux for looking similar.

Re:Getting older and coding

[mckyj57]

I want to play music. 8-)

Luckily, my coding gave me enough money that I can afford to spend a lot of time on that. I still work, but about half-time.

Re:Getting older and coding

[Anonymous Coward]

Sounds like you need a new car and a 20-something blonde girlfriend. In other words you sound like you're ready for your midlife crisis. Some time in the sack with the blonde and a couple of tickets for driving too fast and pretty soon the world will feel fresh and new again.

By the way if it's not obvious. I'm kidding.

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.

Re:Fundamental Flaws

[Anonymous Coward]

It's always nice to run across someone who has all the answers.

Re:Fundamental Flaws

[rAiNsT0rm]

I don't claim to have all of the answers, I do have quite a bit of experience and first-hand knowledge of working on a number of projects over the years. I have seen and continue to see this as the single biggest problem facing Linux, I wouldn't even try if I didn't truly believe in it.

I know you were just trying to be a smart-ass AC, but let me add this... In the same way that I (an individual person) cannot have all of the answers, neither can a lone developer no matter how good their intentions. You need a central *team* of oversight and management to steer development and ensure interoperability and the "unfun" stuff that otherwise would be left undone because it isn't flashy or even seen by the user but contributes to the whole.

Open source isn't about chaos, and that is all it has seen for a long time. Occasionally great stuff will be born from chaos, but to make it all part of a large *orderly* system, there needs to be more focus.

Re:Fundamental Flaws

[swillden]

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

[rAiNsT0rm]

And you sir have summed up the exact problem here. You've glossed over the fact that nothing from NeXTstep just showed up magically working on BSD, it had to be coded from the ground up new. The point was it was done, done well, and in fairly short order.

You honestly believe that 300 half-working yet-another-whatever-app that is just as buggy as the other 299 is better than 1 or 2 excellent apps with more eyes and talent focused on them? There is a point when a million and one false starts gets exasperating for folks to follow. This week it is Compiz, then next you need Beryl, then next week scrap it all and grab Compiz-Fusion, and on and on. That project is actually doing well too... think of all the ones that don't. Every week there is a new hotness, and the program that was #1 for the task last week is already not being developed anymore and another is. That doesn;t help anyone's cause, and the chaos is impossible to hold still long enough to make it truly great.

So with focus things would be worse eh? Tell that to Canonical/Ubuntu. Because they are the closest thing to my theory so far in Linux and they just got into a ton of Dell's and all over the Internet. Why? Because it is a central, slower moving target. I could code for Sally's-Distro-of-the-Week and my work can be made obsolete when she gets a job, a life, hit by a car, or I can put my effort into a distro with a long-term release, huge support and userbase, stable and clear goal (for the most part), and some oversight. If you took all the talent from small projects like Puppy, DSL, Joe-Sixpack's Distro and got them together on one goal the outcome would be tremendous.

The problem is ego and tunnelvision. It can be hard to wrangle a bunch of truly talented folks, and sometimes you don't get your way. Now, you just take your ball and go home to create yet-another-half-assed-distro or app. This isn't about FUN it is about being part of something greater, and the fun you sacrifice to be part of it instead of going nowhere by yourself is reaped tenfold when you get to the end and see what a huge impact you *helped* to create. But that satisfaction is delayed and not as instant as the perceived fun you get by having a few hundred people download your app from your .edu webpage and get some direct feedback... you could have a couple million download it and have your name actually be attached to a major project.

Again, I've heard a thousand people react the way you did... it is the knee-jerk reaction, but I guarantee it is the wrong one. Time will bear it out.

Re:Fundamental Flaws

[Jeremi]

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?

To be fair, Apple is able to do what it does because it can afford to throw bails of cash at the most talented people available to get them to do what it wants. Linux also has access to lots of talented people, but since there isn't much cash available to pay them, the Linux project(s) generally end up with very little leverage over what those people do.... they can either let those people hack at the things that interest them for free, or they can demand that the talented people work on what their 'focus' thinks is important.... and watch the talented people leave the project. It's just the nature of the beast, I'm afraid. (Perhaps companies like Novell can bring in the necessary funds to change this somewhat).

Re:Fundamental Flaws

[pschmied]

Most software shops have dedicated architects. In many cases, those architects can be blowhards with little practical skills, but a good architect can actually do a lot of good for a project. The same can be said of a good project manager.

The strength / weakness of the Open Source model is that it collapses these structures into a flatter skill space. On the bright side, coders get to scratch their itch and prove that their employers' architects are simply wankers that hold them back. On the down side, those same architects are marginalized from the Open Source community unless they work for a company that sponsors major Linux development (RedHat, Novell, IBM, etc). The "shut up and code" ethos of Open Source can create major problems in a project. A lot of times, prolific coders aren't your best coders, and are often abysmal architects (not always, though!). Another downside of missing architects in Open Source is that most architects tend to hold positions of power in commercial IT shops. I suspect the poor integration of architects / project managers / etc. into the FOSS world is probably the reason commercial software is as prevalent as it is.

Think of an olde tyme army that would have had archers, macemen, generals, horsemen, etc. A lot of them were effective because of the separation of tasks and the inherent benefits of combining them. FOSS development tends to lack a lot of those divisions. Consequently, we lose out on some of those modern software development tactics. On the upside we do have a lot of extremely talented foot soldiers.

There's clearly some happy spot for efficient development. Microsoft isn't it. Neither is FOSS, I believe. But efficiency is not the point of either. Microsoft's goal is to produce stodgy software that doesn't change much. FOSS's "goal" is to spin out ideas rapidly. FOSS has been much more successful by that metric than Microsoft has.

-Peter

Re:Fundamental Flaws

[drew]

This isn't about FUN it is about being part of something greater, and the fun you sacrifice to be part of it instead of going nowhere by yourself is reaped tenfold when you get to the end and see what a huge impact you *helped* to create.

And therein lies the problem with your post. To many open source developers, it is about fun. Maybe not in the strictest sense of the word, but these are people who, for the most part, are spending their own free time doing something that they want to do. Telling them that their efforts would be better spent somewhere else is far more likely to drive them off entirely than to get them to contribute work that they aren't interested in doing. You mentioned Ubuntu; Ubuntu is succeeding where others have failed because some guy with a lot of money to burn started paying people to do what he wanted to get done, not because he somehow convinced a bunch of hobby programmers that what he wanted done was more important than their hobby project.

Re:Fundamental Flaws

[rAiNsT0rm]

Sorry, I disagree. The OSS community is leaps and bounds ahead of any single entity such as Apple, and the money has very little to do with it. MAny folks probably work at/for Apple but still contribute and work on OSS projects.

The real issue is the fact that everyone wants their own sandbox, and not to be told what to do or when. It is the wild west. And while so many people think that is kewl and fun, it is inefficient and a waste. Imagine a company running that way, even the best local food co-op's have structure and oversight. Managers and oversight for some reason are seen as a waste (probably because of people's daily lives at work) but it is not always so. Programmer's see graphic designers as a waste too... and it shows in the difference between Linux and OS X, and to some extent even Windows.

It is about stepping outside of your self and your own selfish desires and making something better for the whole. It is also the fundamental flaw in this model, which is why all through history it has failed each and every time be it in government or business. It is so frustrating it makes me want to scream, and has for 12+ years, I am even toying of the idea of speaking at some Linux expos to get this message out and heard. It is absolutely the #1 thing to get resolved before Linux will ever go much further.

Re:Fundamental Flaws

[rAiNsT0rm]

Very well stated! I do agree for the most part with you and I wish more folks were as level headed and could see this as clearly. I, however, believe it is the view because of people's normal life experience with *corporate* management and architects. I'm not tooting my own horn, but I manage a very large network and team, and I am one of the most talented and skilled managers because I'm not a hands-off guy and have tons of experience in the trenches. I don't do well in corporate management for that reason, and there many other like myself and in all areas including development/coding. Just because you have some PHB who got to his/her spot via some underhanded dealings or other B.S. doesn't mean all managers are the same.

It is about seeing the bigger picture and stepping outside of your own little box and truly making a difference and making something revolutionary. But revolution does not stem from chaos.

Re:Fundamental Flaws

[swillden]

You've glossed over the fact that nothing from NeXTstep just showed up magically working on BSD, it had to be coded from the ground up new.

I'm not sure whether you're talking about the original development effort or something more recent. Just to be clear, NeXTstep was always on BSD.

In any case, your rant completely misses the point. You came closest (by virtue of being most wrong) when you said:

This isn't about FUN it is about being part of something greater, and the fun you sacrifice to be part of it instead of going nowhere by yourself is reaped tenfold when you get to the end and see what a huge impact you *helped* to create.

There are a lot of OSS developers, and they all have their own reasons, but FUN is a *huge* part of it for most of them. For example, I'm a professional software developer, have been for nearly 20 years, and I often find that the stuff I work on at work isn't all that interesting. So, in the evenings when I'm not busy with all of the things that come with having a life and too many hobbies, I write OSS code. I pick things that I think are interesting and fun and I contribute there.

There are other motives, of course, and I think it's fantastic that Canonical, IBM, HP, Red Hat, Novell, Sun, MySQL, Trolltech and dozens of other companies are paying people to work on OSS full-time. I think the work that Canonical has done, by providing an intense focus on polishing rough edges, is excellent and very valuable. BUT... that in no way devalues the contributions of random hackers scratching their personal itches, because for all that the full-timers do, it's the random hackers that do 90% of the work, and it's due to the efforts of the random hackers that the guys at Canonical etc., have a diamond they can polish. The polish is useful, and unlikely to come from random itch-scratchers, but it's only polish.

There simply isn't enough money in the OSS business model to justify full-blown from-scratch development a la Apple and Microsoft. The key to making the whole thing work is all of that chaotic development that you decry. Without that, Canonical is nothing, Red Hat is nothing.

And you simply *can't* direct, or manage, or focus, the efforts of people who are scratching their own itches, entertaining themselves on their own time. The moment you begin to direct them, their work ceases to be enjoyable and becomes just another form of the same crap they get at the office. To achieve any sort of critical mass, OSS needs both the chaos and the people who grab the chaos and try to order and organize it. Even that is an oversimplification, because even the organization of the software benefits from the chaos of multiple approaches to organization.

You'd like to force-fit the bazaar into the cathedral, but actually doing it would destroy it. The status quo is better: The bazaar produces all kinds of weird and wacky things and folks from nearby cathedrals cherry-pick the best, polish it up and integrate it into a cohesive whole (and also offer the polished pieces at the bazaar, plus a few of their own).

Re:Fundamental Flaws

[bit01]

You're automatically assuming that everybody wants one "Linux". You're wrong. It's way more complicated than that. Your push is just one more example of "if only we had control everything would be more efficient" beloved of growing bureaucracies everywhere.

Instead you should be concentrating on standards, one at a time, as many people already are. Everything from the Linux Standard Base to the Free Desktop Project to the Linux Embedded Consortium. Keep in mind that if you're going to promote standards, one at a time, that in a free market each player needs a transition path and to not to be disadvantaged by the standard. For example, if all distributions standardized on the apt package manager that would be a disadvantage for all distributions not using apt. The only way to get a standard in package managers, or anything else, is to have it sufficiently superior, technically and otherwise, so that important projects are willing to absorb the transition cost and to accept being relatively disadvantaged during the transition compared to other projects.

In any case complaints about "having to support too many distributions" are exaggerated; when you've got software packages as complex and big as open office and java running on a variety of platforms, not to mention the thousands of small projects on freshmeat running on a variety of platforms, that's an existence proof that the problems are exaggerated.

In addition, for better or worse, every business wants to "differentiate" too, just like the car industry where I can't use a Toyota spare part in a Ford. After market car parts companies probably don't want to deal with all the different cars either but they do anyway.

Some closed source embedded device driver developers are unhappy the Linux binary device driver interfaces are changeable. Linux kernel developers have already explained why that is the case ( http://www.kroah.com/log/linux/stable_api_nonsense .html ). It's pretty pointless making an open source OS if some vendors want to obviate the whole point of it by adding close source device drivers, particularly when kernel developers have offered, for free ( http://www.kroah.com/log/linux/free_drivers.html ), to support the device drivers themselves.

There's always room for improvement but you're never going to get a free market to "standardize" entirely on anything.

---

Monopolies = Industrial feudalism

Re:Fundamental Flaws

[rAiNsT0rm]

I'm not sure how I or anyone can be "wrong" about their opinion, but I will try to respond. I 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. I'm not saying these overlords need to be cracking a whip and forcing you to code a burning program when you want to make a new notepad... 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.

I'm not trying to jam any square pegs into round holes, I'm trying to have some method to the madness (and no it money has no part in what I am saying). Just as boring as some of your daily tasks are, so are the days for us managers... especially managers who are skilled and talented and not just a PHB (yes, we exist). I'd much rather be helping to steer a big ship destined for something truly great, rather than listen to people bitch about Suzie in the next cube's radio or hearing yet-another excuse as to why you need every Friday off for 5 months.

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. They lead just as unfulfilling professional lives too and would be a breath of fresh air.

Re:Fundamental Flaws

[rAiNsT0rm]

I've never said things need to be standardized entirely. In fact I'm saying the opposite, there needs to be a solid foundation. Foundations are stable, not chaotic, and easy to then be creative and build upon. Why people continue to believe they can prove years of history wrong, and keep plodding along this path is beyond me. Sure there will be flashes of brilliance, and some areas may flourish, but it will not work as a whole.

We don't need government, we need guidance and steering and direction from some point above the coder level. Imagine the state of the kernel without it... now, why again do you think this is not the case with the rest? You are fooling yourself.

Re:Fundamental Flaws

[swillden]

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

Re:Fundamental Flaws

[rAiNsT0rm]

I respect your reply, but I still think you are missing it a bit. Just as you admit artists/designers are needed, there is no avenue for them to get involved. They can't gain respect via writing code, they can gain respect by creating an environment that fits their style and opening up and asking for their help and input. You can't shoehorn them into a logical system that might make perfect sense to a coder, this has never been done to my knowledge.

In that same vein, you are minimizing management which is common and a terrible shame. You even point out how those coders of the kernel have now become "managers" and how well it works... I am saying the same thing but on the rest of the system.

Again the aversion is due to inept and B.S. managers that you and most everyone deals with daily, that is not representative of *all* managers and nothing is stopping some of the long standing app authors from taking on that role and keeping their respect. I'm not suggesting we just get a bunch of managers involved or "pure" architects. Nothing drives me nuts more either. As for my background, I have over 14 years in IT and have helped to create and run a number of multi-million dollar *innovative* companies. I now run one of the top University networks in the U.S. and am not just some schmuck with pie-in-the-sky ideas. Again, I truly believe in what I say and I am adamant about it because over the years I see the same thing over and over and it is maddening. I do have the capacity to gain acceptance and speak at conferences and as I continue to speak with others involved in OSS I am taking note of opinions and criticisms I grow closer to building a comprehensive speech that covers the most common reactions and objections.

Re:Fundamental Flaws

[swillden]

Just as you admit artists/designers are needed, there is no avenue for them to get involved.

This isn't true on any of the projects I participate in. There are regular calls for them, and the ones who speak up are respected and listened to. Most developers are well aware of their own limitations in these respects, even those of us who have some artistic aspirations.

This is Good

[EmbeddedJanitor]

It is far better to have the more experienced folk checking the contributions of others. This builds a broader base of contrubutors and the more seasoned folk get to ensure that the Good Stuff is getting in to the kernel/whatever.

Experience does count, and age is not a limitation. There's a myth that older people can't program. At 45 I reckon I can outprogram most youngsters, but it is probably more valuable to be mentoring others. I know a few very active programmers in their 60s and even 70s.

Old good programmers should not become managers unless they are actually better managers than programmers. Programming is not a science or an art, it is a blue-collar skilled trade. Knowledgable older programmers should be helping out the youngsters.

Microkernel

[zymano]

minix.

No brainer ...there are too many lines of code...

[chicagozer]

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.

kurt strikes again

[Anonymous Coward]

"Everybody wants to build, but nobody wants to do the maintenance."

Thanks Kurt, you ruled.

Natural Evolution

[tji]

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.

Your best interests are not my best interests

[Rix]

You're free to go off and do your own thing if you don't like the way the rest of us do it. I couldn't care less what you think needs to happen. Either do it yourself, or shut the fuck up about it. I'm not going to do it for you, and I highly doubt anyone else will, either.

I don't want to build a mansion. I like my sandcastle. If you don't, piss off.

Re:Your best interests are not my best interests

[rAiNsT0rm]

Great attitude, and you are not alone in your opinion. I'd rather not have you in my house, and instead being the king of your own little sandcastle. I'll be sure to kick it right the fuck in your face as I go.

Where is the logic?

[Anonymous Coward]

"Top Linux Developers Losing the Will To Code?"

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

Seems like if they were just "losing their will" they would be resigning

Don't feed the Taco troll

[John Jamieson]

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)

Stop coding, start designing

[bug1]

Speaking from my own experience, i found that what motivates me to code has changed over time.

First it was the technical challenge;
Second the challenge was to earn money from my skill (not very successfully)
The challenge for me now is design.

I see free software as an art, code is just the medium in which a design is implemented.

I dont care if my project has fancy features, i dont care if time spent on it can be justified from a commerical perspective. Its just about solving a problem that people (developers) can one day look at and realise its the way it should be.

Art is really what seperates commercial code from free software, if you spent an hour thinking about a more appropriate variable or function name on a commercial project your boss wouldnt be impressed. But its little things like this (and design) that lower the level of participation, enabling them to get the "many eyes" that improve it.

Free software programmers are like the artistic painters.
Commercial programmers are like a signwriter.

Deadlines can only lessen the quality of code.

And that...

[Rix]

Is why no one listens to you, you laughable little man.

Re:And that...

[rAiNsT0rm]

awww, jeez you hurt me deeply.