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

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:

[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 [wikipedia.org], applied to labor.

Better management...

[SanityInAnarchy]

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

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:

[mwvdlee]

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

Re:

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

Re:

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

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

Re:

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

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 prog

Re:

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

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:

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

Re:

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

Re:

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

Re:

[cp.tar]

Sure... if it compiles, ship it.

a good or bad thing?

[brunascle]

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

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:

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

[bjourne]

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

Re:

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

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

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

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

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

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

Re:

[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

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:

[TheLink]

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

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

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

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 [wikipedia.org]:

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:

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

Re:

[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 [ivtvdriver.org]). 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 [kernel.org]. It'

Re:

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

[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

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/ [lwn.net]

Re:

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

[janrinok]

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

Re:

[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/ [oreilly.com]?

Re:

[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 [amazon.com]
• The Linux Kernel in a Nutshell [amazon.com]

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

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/ [kroah.com]
And sample code for a USB thermometer
http://www.kroah.com/linux/talks/ols_2005_driver_t utorial_example_code.tar.gz [kroah.com]

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

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:

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

Re:

[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

Re:

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

Re:

[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

Re:

[Hognoxious]

Is something like this [lwn.net] what you mean?

Re:

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

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 g

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 other

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

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.

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

Circle of life!

[ceeam]

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

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.

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 [archive.org]

;)

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.

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

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:

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

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

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

With focu

Re:

[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

Re:

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

Re:

[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

Re:

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

Re:

[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

Re:

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

Re:

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

Re:

[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

Re:

[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, on

Re:

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

Re:

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

Re:

[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

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:

[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

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 relation

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)

Re:

[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

Re:

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

[TheLink]

Python and Ruby?

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

I can't decide... ;).

Re:

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

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

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

[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 [wikipedia.org].

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.

Re:

[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