Slashdot Mirror
Shuttleworth on Open Source Development
An anonymous reader writes "Mark Shuttleworth (retired cosmonaut and Ubuntu daddy) has written an informative blog entry about the problems associated with open source development. He found that paying geeks to code without assigning them managers lead to "shiny geek toys", rather than the product he was actually paying for. Shuttleworth says that left-field thinking is required when it comes to managing open source teams. See also Andrew Orlowski's analysis of why AOL eventually killed the Netscape project from a few years ago, where he describes Mozilla developers as "wandering off into Lotus-eating land"."
You can have all the creativity you want - but without proper leadership, all that effort and talent goes wasted. I have a few creative friends that have all these wonderful ideas - but they have no idea on the concepts of project planning or management of resources. Needless to say, their killer applications are still brain children - and not actually out here where the rest of us can use them.
that shiny geek toys are all that bad. I can't think of one thing that my grandmother (who is as far from a geek as one can get) uses every day that wasn't once a shiny geek toy to someone.
-- This post contains %100 recycled electrons Remove spam and eggs to send some mail.
Do ya think? How long did it take him to reach that conclusion?
Seriously folks, this is a given and one of the main reasons I don't buy into all the hype about the electronic toy du jour. Everytime I see an article somewhere which says that 'X' is the latest electronic whiz toy that everyone must have I just roll my eyes and move along. (As a side note to marketers, I don't watch your commercials or read your flyers in the paper. You may now explode with unmitigated rage because I'm stealing from you for not watching what you produce.)
I don't want to be forced to buy a DVD player which plays DVDs, mpegs, connects to the net, calls my vet or offers me advice on what wine goes well with acadian rigatoni. I want the machine to play DVDs. Period.
By their very nature geeks (true geeks) will shovel every bell and whistle into a device they can get away with because that is what they do. They want to see how much cruft they can tack onto the hardware simply to see if it can be done. Top that off with manuals (the paper ones if you're lucky enough to get one) which are so poorly written and obtuse that the average user has to take lessons to learn how to program their device, and the market becomes filled with devices whose half-life is as long as the life of a fruit fly.
To all who produce this crap, here's a hint: Stop making a swiss army knife out of every product. If you absolutely must put tinsel on the tree, make three trees. The first is bare bones (i.e. just a cell phone. no music, games, etc). The second has a few more items (include games and music). The third has everything (bleeding edge). If you check your sales figures you'll be surprised to learn which one sells the best (hint: it's not number three).
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
I agree with most of what he said, except I don't think its limited to open source projects. I have seen that on purely commercial context as well. The problem is that you *need* some kind of "geek toys" occasionnally, because they sometimes give birth to a very valuable technology (I've seen that many times). That's a complex task to find the fair balance between what is reasonable/valuable and what is not in term of focus diversion, and that's a hell of a management task to deal with people who can't see that balance (either way).
It sounds like he hired a team of talented but flakey developers and is generalizing this to all OSS development. I don't think the problem has anything to do with OSS - it has to do with a team of guys thinking they have free reign to do what they want with no expectations, deadlines or oversight.
my sig's at the bottom of the page.
Strong architectural design definitely helps. However, it's not the be-all-to-end-all. In OSS development you have to be aware that your programmers are volunteers. They can and WILL step out the door at inopportune times, start arguements over architectural designs, and spend time working on what they think is cool rather than what is needed.
To get a project to absorb much of this chaos, you can do a few things to help the project:
Javascript + Nintendo DSi = DSiCade
As far as I could see, very little in the way of specification, design / architecting.
Without a reasonable framework it was inevitable the project collapsed.
The actual coding should be a minor part of a project, the real blood, sweat and tears is the spec and the architecting / design (and usability / test side of things): If that is done well enough then the coding should be a simple join the dots task.
Without architecture / design constraints then you will get toys for the boys (and girls) as there is no pressure / direction on them to do otherwise.
I always kept wondering what exactly XUL was developed for when a browser was needed. I don't know the timeline, but wasn't Gtk ready about the time they started Mozilla? I know that Qt was for a long time worthless for cross platform free stuff, because Trolltech charged money for the win32 version (which they had every right to do so).
http://www.schooltool.org/
Summary of current status as I read it: SchoolTool still isn't really there, but they did manage to get the spinoff 'SchoolBell' out there, and the SchoolTool work is ongoing and being included in the 'Edubuntu' distro.
This has nothing to do with Open Source. It is about trying to develop a product without a spec., without an architect, without management and without a timeline. Kind of like pointing a group of carpenters at an empty lot and telling them to build a school.
It wouldn't be any more or less successful at Microsoft, IBM or SAS.
...is still valid? Do one thing, do it well.
Imagine that - simple, solid advice survives time. Reminds me of the Twelve Networks Truths of RFC 1925 Section 2-11
BSD is designed. Linux is grown. C++ libs
Mark Shuttleworth is subsidizing the Kubuntu team is working on a software installer named Adept. I find this to be rather wasteful, since there is already an extremely feature-rich, robust and mature installer from SUSE named YAST. YAST is Free and Open Source (GPL) and it is built on the Qt/KDE framework and integrated in the KDE Control Center, so it would fit very nicely in the Kubuntu environment.
YaST is the app that makes the proverbial "Linux on the Desktop" a reality. It is the most robust, comprehensive and user-friendly configuration tool for GNU/Linux -- software management, hardware detection, system administration and much more. In short, it is everything the average newbie from W$ needs to set up and update his computer without having to touch the command line.
Devising a new GUI app for installing packages is reinventing the wheel by duplicating the gigantic functionality of YAST. This project will only yield a half-baked solution that will get abandoned as soon as it starts tackling the more thorny issues that YAST has already solved.
The YAST code is clean, and has already been used by Linux distros like Yoper, so it is definitely feasible to get it running under Debian/Kubuntu if their devs don't start reinventing the wheel. YAST might be complex, but then any program that excels at setting up and updating a Desktop Linux system is going to become complex no matter what.
Get computers and accessories from Linux-friendly manufacturers
It was an interesting article and well worth reading. But the fact that this is 3 years old is relevant in my opinion. I'm a little put off by the fact that this wasn't noted in the excerpt for the headline. Submitting this and passing it off as current news for the sake of making a point is bad form. This particular blog isn't new at all and so you know that someone didn't submit this just because they found it for the first time today and thought it was valid. Its a lot more likey that someone wanted to make a public point about open source software and dug this blog up out of the archives in order to do it. It you can find a newer link than this to make your point, then maybe this particular view is outdated and not worth spending very much time on.
Part of what makes Linux and GPL'd software so nifty is that with access to the source code one can do all sorts of wonderful and unexpected things. Port wondershape to the wrt54g. Replace svgalib with aalib and seamlessly render images and video streams as ascii art. Fit linux onto all sorts of silly places, including a windows device driver. Tune the linux scheduler parameters using adaptive genetic algorithms. Cook up packages for compiz before the distro puts it into stable. The ability to think outside the box and hack things in this manner is simultaneously the strongest advantage OSS has, and it's greatest obstacle.
.deb, that sort of thing. Something the team wants to be successful and proud of.
The greatest obstacle? Firstly, if you simply hire people familiar with open source, those who recognize the value of the above traits, you're likely to get something that satisfies their needs not yours. Maybe that compiz package requires a lot of extra effort on your part, because nobody's written a script to handle the simple textfile changes nessecary. Secondly, integrating silly hacks back into the core is a challenge. On the one hand, integrating them into the core encourages more, which we like. It also means that the hack gets all the benefits of future improvements. On the other hand, not every hack is easily maintainable, nor easily integrated. Every time you reject a patch, you discourage people from offering in the future, and the risk of someone pissed off and forking your project increases. Not that forking things is always bad, but a fork in spite is bound to not only divide resources but increase overheads, potentially causing a net loss in future value of the software.
Shuttleworth believes he can fix this by making communication among groups more explicit. I doubt it will improve anything. On his next attempt, perhaps he should make his team a stakeholder in a very dear sense. Not bonuses for completion or anything silly. Make them run a school with the software -- Eat their own dogfood. The core team will have to shift their focus on making the software work for them in ways similar to other schools. Maybe they could start a school about hacking on OSS. Teach the newbs the labrynthian ways of the autotools, how to take a tarball and make it a
I Browse at +4 Flamebait
Open Source Sysadmin
what we need is not management BUT
-payment to coder only when the product meets requirements
(why did anyone get paid if all you got were shiny toys!)
-select coders who can self manage
-peer review
Peer Review is very important! You could have college students doing it, as long as someone goes in there and checks that the code does what it says it should.
Was in process of moderating but removed my moderation to make this comment
Seems lots of places do quite well with egalitarian structures. No-one complains about India, Japan, China putting out shiny geek toys or wandering into lotus land even though they don't have American "org charts".
The issue is more to do with programmers who can't stay on track rather than programmers who ignore the "org chart".