Slashdot Mirror
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."
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...
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"
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.
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.
Your ad here. Ask me how!
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.
Developers: We can use your help.
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.
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.
---- Teach Peace. It's Cheaper Than War.
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.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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.
Fork.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
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.
... 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).
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.
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...
If you only have X hours to spend on a project you should choose the activities that will be most beneficial.
As much as technical guys don't want to think about it, good management is an excellent productivity multiplier, alternatively no/poor management is a productivity destroyer.
Some well directed management and control will often result in the team getting more additional work being done than if the "manager" did it himself.
Think about all the times the senior guy, or the suits rejected blocked or otherwise stopped something you thought had great value. You should consider that perhaps if YOU were the manager, some of those good things would happen, you might be more useful doing the managing than technical work.
As the number of contributors grow and the network becomes more and more complex you NEED management who understand the task at hand. Dilbert, and I'm sure most people out there, suffer from BAD management. We all know how bad management can doom a great project.
I am sure that they miss coding but are they working on linux to satisfy their own coding desires or to make linux a better product. If it is the former then they have no reason to be in management, but if it is the later then they are needed where the are. As the network gets bigger and more complex we are going to need people who have a better grasp of the BIG picture. Without this linux will die.
Here is a tutorial from Greg KH from Ottawa Linux Symposium 2005 (and 2006):t utorial/t utorial_example_code.tar.gz
http://www.kroah.com/linux/talks/ols_2005_driver_
And sample code for a USB thermometer
http://www.kroah.com/linux/talks/ols_2005_driver_
If that means that Greg can stay away from coding/designing another jewel like UDEV, I see that only as a Good Thing.
...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?
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.
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.
Je fume. Tu fumes. Nous fûmes!
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.
At the bottom of the
Perhaps you need to get a little deeper into kernel development to find out why Eiffel is a bad choice:
In summary languages that do stuff for you behind the scenes suck for kernel development.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
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.
I prefer the "u" in honour as it seems to be missing these days.
LISP machine kernel didn't have to worry about virtual memory management.
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
- 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....Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
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.
More appropriate caption would be "Top Linux developers are replaced with new ones as time go by".
Losing, not loosing, for the sake of Webster's spinning corpse, you damnable corpse-spinner!
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.
Linux is just about finished right now. Just wrap it up and ship it.
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 :)
Perhaps this is the problem
d ilbert.com/comics/dilbert/archive/dilbert-20030619 .html
;)
http://web.archive.org/web/20030620163003/http://
--I thought I was wrong once, but I was mistaken.
Top Linux Developers Using the Wii To Code!
Oh, how I wish some of my day job bosses had ever written a single line of code in their lives...
Don't thank God, thank a doctor!
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.
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.
:wq
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. :-)
Keep the Classic Slashdot.
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.
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.
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.
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.
http://teasphere.wordpress.com - A little spot of tea
You're right, you wouldn't. People who spell it the modern way, Lisp, however, would.
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.
Engineering is the art of compromise.
minix.
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.
ZZ
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 :-)
Slipping shoelaces ?
"Everybody wants to build, but nobody wants to do the maintenance."
Thanks Kurt, you ruled.
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.
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.
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.
Please, for the good of Humanity, vote Obama.
"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
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#.
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.
Sam ty sig.
* 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.
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)
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.
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.
Please, for the good of Humanity, vote Obama.
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.
Je fume. Tu fumes. Nous fûmes!
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.
Python and Ruby?
;).
But PHP seems awfully popular. Or should I say terribly popular?
I can't decide...
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.
Is why no one listens to you, you laughable little man.