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"."
That's why IE is *sooo* much better than FireFox!
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.
From the article:
This entry was posted on Friday, November 21st, 2003 at 6:48 pm...
A little out of touch maybe?
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.
I also agree with this:
I really hated Internet Explorer. When I heard about Mozilla, I tried Milestone 8 (around 1999), and it was slow as a snail on my poor machine. WTF were they thinking? The Netscape code might have been difficult to maintain, but what really needed a revamp was the html renderer.
The reason Firefox did get a huge market share is not because of the XUL framework, but because it was finished. I'm sure all that delay could've been avoided.
I think his project ultimately would have been successful if he'd started with a strong architectural design. Get the documentation out there first and get the developers coding to it, rather than to some nebulous desire for a GUI tool. An architect would also have made a GUI decision, either picking XUL or some other framework, or he certainly could have designed his own. But to let the programmers run without focus was simply asking for what he got.
John
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
"So I canned the project and shutdown the development office, letting the developers go."
For Pete's sake, don't anyone let my boss see that !! O.O
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.
Ok. For those that didn't realize it, that blog entry was from 2003. Today, three years later on, where is the SchoolTool project? Did Mark really learn a lesson and develop a solution or did he just relive a trend he noticed so long ago?
Seems to be a long development cycle for a specialized calendar. I'm glad I'm not paying for it.
"informative blog entry" - is this even possible?
I'm not sure exactly how it went down, but it sounds like he hired a bunch of developers for a project and just sent them off to go do it without leadership. This isn't a problem with open source, it's just a boneheaded decision. When you hire someone you have to train them and tell them what you expect. It's no wonder that they gravitated towards whatever they wanted to do since they had no direction.
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.
In that case self-management is the key. I've been there. Working for years in an educational environment where the actual workload was less than 20 hours, I had a lot of freedom to take things in new directions. I ended up coming up with some of my best ideas and was able to develop the discipline to implement them. But it was really hard not to get distracted. You have to develop a manager mentality--be results oriented. As a programmer / designer / creative, sometimes spending 8 hours just researching or learning something is well worth it, but at some point you have to jump in and focus hard on the final product until its done. Then you can go back into creative mode and dream up version 2.0.
...this article is more than 2 years old:
This entry was posted on Friday, November 21st, 2003 at 6:48 pm
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.
But it's often these oddball programmer projects that end up being the next big thing. Manage your coders but don't stiffle them. I think that's the real secret to Google's success and it can be yours too. Steer them towards finishing your projects and finishing their own projects.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
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.
Time spent making those shiny toys is not time wasted. I can see him getting mad because he is paying them, but personaly, I think that those geek toys are great for me. Hehehe.
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.
Actually, Orlowski reasons for deriding the Mozilla team in "wander[ing] off into Lotus-eating land" are:
"creating esoteric frameworks". Later we learn that means "Creating a neat C++ framework when what the world really needs a non-Microsoft browser is nothing but a deriliction of duty: a piece of vanity code". Except http://weblogs.mozillazine.org/ben/archives/009698 .html/ shows XUL creation was a direct effect of AOL pressure on advertising and netscape portal integration
"note-perfect bug tracking systems that only a nerd could appreciate". Anyone who ever looked at bugzilla's internal knows it's a quick and ugly hack who could never mobilise a whole team for years.
So when Orlowski writes jokingly "corrupt suits at AOL" "betrayed the Great Noble Project" he's right, and when he rants about nerds he's dead wrong (you'll notice once the inspired suits where taken of the picture the nerds did produce a successful browser).
If anything, returning on Orlowski's pontifications today only emonstrates the depths of his prejudices and cluelessness.
...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
Your statement is so confident that I'm sure you have put a lot of thought into this (or you just don't have much of an imagination). I'm not arguing this way or that, but I think this is really thought provoking.
What are your favourite Shiny Geek Toys of the Past that your grandmother uses? What is Teh Ultimate Shiny Geek Toy of the Past? Could it be the wheel? Or a hammer? Toilet must be on the list (got to have them shiny). Shoes, maybe?
Other ideas?
Speaking of managers, we need one at the Ubuntu art team. It's insane to see that place's activity painted by uncreative icon set wars. All while there's minimal organization and whenever you DO finish something interesting, it's too difficult to figure out how to get the right people to notice it. There's zero management, and therefore there's nothing useful happening with the time that people seem to put in it. Like stated, this leads to "geek toys".
I'm not even being a troll here. Ubuntu artwork development would be very well-off having SOME sort of centralized body to coordinate efforts.
"retired cosmonaut"
He paid a bunch of money for the Russians to take him up. "Retired space tourist" maybe.
Well I understand that in 2003 cross-platform development wasn't possible as it is today. So I think Mark Shuttleworth should try again but start with wyoGuide (http://wyoguide.sf.net/) as it's base. wyoGuide also uses wxWidgets as does Chandler. I'm quite sure the outcome would be completely different then it was in 2003. The success doesn't only depend on the people in the project but also on the tools these people can use.
Besides wyoGuide can be used for any cross-platform development project.
See http://wyoguide.sf.net/papers/Cross-platform.html
I think it can be summed up that Open Source faces challenges when the developers are working on code "for other people" not themselves. Two of the most successful Open Source projects are GNU (excuse me, Free Software) and the Linux Kernel. I think you can categorize both of these as situations where the developer is classified as a user of the end product. It is in their interest to make the best product possible because it actually helps their own cause.
The case of the SchoolTool was that it was being developed by developers who didn't have a vested interest in making it work or at least faced no consequence if the tool didn't work.
Not to open another can of worms but I think this can extend to other situations such as Desktop Environments. A lot of talk about making stuff "Grandma Friendly" or similar mantra removes the developer even further from an interest in the user experience rather than add the focus people are hoping for.
-Eyst
I don't think it's necessarily a problem of leadership, or vision, or management. You just have to be able to specify what you want, and for that, you have to know what you want, and what you don't care about. Programmers are generally very capable, as long as the task is well defined. Just specify what parts of the finished work are critical, and what parts have leeway: "For this aspect, I don't care how you implement it, as long it does this, this and this." And then check periodically to make sure the progress is going according to plan. The last thing you want is, "OH, you wanted the text editor to allow MORE than two pages of input! Now I have to redesign it!" Yes, that actually happened to me on some code I contracted out. And the programmer was not stupid -- he added a lot of useful functionality and made good suggestions.
Rank my idea: http://www.sinceslicedbread.com/node/531
This sort of thing is a general problems with developers, and how it manifests itself depends on the environment.
In fact, it tends to be more a problem with closed source projects in large companies (as well as with lavishly funded open source projects). Why? Because the developers in large companies are well funded, they can go on forever doing their pet things, and upper management is often easily fooled about what's going on. The only reason Shuttleworth caught this is because he has a clue. Arguably, most of Vista is like that, although there the problem isn't that Microsoft management doesn't understand what their engineers are doing, it's that Microsoft management has the same set of warped gearhead goals as their engineers. It's also the reason why the Java enterprise platform is getting ever more bloated and unwieldy, while most real people write stuff in PHP.
In contrast, many open source projects, as Shuttleworth observes, are projects that have "an itch to scratch"; the code may not be pretty, but it helps get the primary jobs of the people who are developing it done--and their primary job is not to create complex software systems or re-invent XUL.
It's not reasonable to blame developers for it--after all, they aren't generally paid to make customers happy, they don't benefit from happy customers, so why should they care? Developers have to worry about making the resume look good, and a bigger, more complex project using the latest technology looks better than pushing a small VB or PHP app out the door.
So, if you're funding open source projects, make sure that you're getting your money's worth and keep in touch with the engineers you're paying. And if you're a manager in a big corporation with a large software development staff and you actually care about delivering good software, you have your choice of jumping off a roof or changing jobs.
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's true, if you want to realize a vision you also have to do the work. It's almost impossible to transfer visions to other people, so Mark should have at least participated in the work himself.
I've myself a vision
http://wyoguide.sf.net/papers/Cross-platform.html
let's see how far I come.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
Developers of OSS often forget that they have two choices in most cases:
1) Meet the needs of their users and especially those who want to use their products
2) Meet their own needs
OSS developers need to stop using the argument that "feature X is missing because we're hobbyists." If you want to compete with the big guys, you need to give your users the features they want. It's certainly your right to prioritize based on your wants, but don't kid yourselves. If you don't give the users what they want... they'll leave.
He was really going about it the wrong way the first time, and he was still going about it the wrong way the second time. What he should have done was start by hiring a retired school administrator who is willing to play with computers (but doesn't necessarily know anything about them). Then somebody who to keep the computer working. Then a couple of developers, chosen mostly by the school administrator based on whether they find the manager's excitement infectious.
You always get shiny geek toys. Knowing this, what you have to do is make the result you're after the most shiny thing around. It's probably too hard to find a group of developers who are mostly interested in school administration, but you can get the programming skill and interest from different people, so long as the people mix well. Of course, ideally, you want to enlist users as soon as possible, too, because even someone who used to need the software but doesn't now is going to have less of a focus on getting it. Pick some school system that's really in bad shape organizationally (so what you can do quickly is an improvement), get the people who would use the system to spend the summer working with the project, and actually use it in the fall.
This gives the team pressure to have something working and useable and real soon, so they don't get sidetracked into all the millions of things they could work on, which would advance the state of the art but not actually lead to the actual goal.
Take note: In the Orlowski article, the line following the bit about the lotus-eating is: "Both these points of view are caricatures, of course." Thanks to the poster for the sensational, and ultimately false, summary.
I agree.
I know there's a bit of a bias here on Slashdot -- and among developers in general, IMO -- against "manager types" and non-programmer software people (e.g., Analysts, Testers, Documentation Writers, etc.) but I think that one of the weaknesses of a lot of OSS projects is that they're full of nothing but coders, and very few 'ancillary people.'
I'm sure that makes for lots of code, but I'm not sure that it leads to the best final product. There's a reason why analysts and testers exist on commercial software projects (sometimes in greater numbers than actual programmer/developers!), and it's not because commercial firms like paying extra people's salaries. It's because projects work better when they're well thought out and well-documented and when there are people around who's job isn't writing code.
I'm not saying that every OSS project should go and follow the SEI CMM guidelines like a recipe, or any other top-heavy "development methodology," only that there seems to be this rampant attitude in the OSS world that the best way to solve a problem is by a throwing half a dozen programmers and three cases of Jolt cola into a room, and not letting them out until it's fixed. Maybe that's not always the best way to do things.
I think, as a community, we're very slowly getting to learn that.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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.
...and he probably would've had a better product in the end. I think alot of the best open source software out there became great, simply because the developers *weren't* getting paid. It was a labor of love -- they saw something great, grabbed a CSV account and started contributing. You can't just throw money at people and expect them to follow your vision, especially if you're not there to lead and manage.
body massage!
Geez, the guy posts a minute after the previous post (so he probably didn't see it) and he gets modded -1 (redundant). Won't anyone think of the latency?
Blasphemy : Mark Shuttleworth and Andrew Orlowski in the same Paragraph Mark is a God, I am in homage to him, (also as a Ubuntu user) Fellow "/.ers" Andrew Orlowski is a pathetic writer, that does not share any of our views.. wikipedia sums it up better than I do . http://en.wikipedia.org/wiki/Andrew_Orlowski
"Shuttleworth says that left-field thinking is required when it comes to managing open source teams."
I think that vague, meaningless terms are required when it comes to writing about managing open source teams.
I spoke with the project manager for SchoolTool last year when he was at an educational conference in my area. He said that what Mark basicaly learned with the first (Java based) SchoolTool is not to start a project and then go into space. Goo advice for anyone committing to large product development.
The current SchoolTool is being written in Zope3 and is under tighter development control.
This is very old news and does not reflect the current understandings of either SchoolTool or Marc Shuttleworth. This article could also be called "My first babysteps in the universe of Open Source development", file under ancient history.
Kind Regards
"A few great minds are enough to endow humanity with monstrous power, but a few great hearts are not enough to make us w
Of course, it may be their product managers so infected, and not so much the programmers, as I can't imagine programmers being that enthused over Group Policy Management Consoles...
Certainly Microsoft is the home of "Lotus eating" when it comes to security and reliability. I mean, their antispyware product disables Norton Anti-Virus? Who thought that one up?
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Funny to see this piece dredged up again. I'm the blogger Mark references in the story, Tom Hoffman, and for the past year and a half I've been managing the renewed SchoolTool development effort, after Steve Alexander created a new Zope 3 based architecture.
It is definitely tricky to manage a project with such broad and lofty goals, and we've still had our share of mis-steps and mis-directions. I have a background as a teacher and self-taught Zope hacker, so I've learned a lot of lessons about software development.
Nonetheless, a useful application is in sight. We'll have a beta this spring and serious testing in real schools in the fall of 2006. One key this time around was keeping the burn rate down and not creating specific expectations in schools and with governments that we subsequently failed to meet.
If you're interested in open source software for schools, check out http://schooltool.org./
> Leadership is needed!
Why?
> In every project, no matter what it is, whether it's open source or sending
> a space probe to Pluto. There will always be decisions to make that is not
> going to be in favor of every person on the team.
That explains why absolutely unanimous decisions are impossible. So, we have identified one system that doesn't work; why do we need -one- leader?
Why not one-man-one-vote? Why not voting by proxy shares, given out for lines of code contributed? Why not polling the user community and allow the developers to veto bad ideas on technical grounds?
There are probably hundreds or thousands of decision making protocols you could use.
> Sometimes you have to cut down, cut away, change and sometimes that process
> can be painful. Without someone who has the final word, anarchy and a "new
> geeky shiny thing" is the result.
Yes, you need to edit sometimes. Why does the editor have to be some "one"? Why not some two? Some nine? Some twelve?
Why is one leader superior to one group voting or blackballing? It's faster, but is it better? And if so, why?
I think it comes down to understanding the unstated requirements and assumptions and being able to communicate those to everyone.
If you can get past that, then management is very simple.
The *business* has a goal of shipping product X on date Y to make profit Z.
Unstated is the requirement that it doesn't have to be perfect. Just "good enough". And, exactly, what "good enough" means in this situation.
I can ship any product on any deadline provided that there are only 2 requirements:
#1. It doesn't have to work.
#2. I don't have to maintain it.
Now, the great manager will also be able to communicate the unstated requirements and assumptions of the programmers to the business people. AND get them to UNDERSTAND them.
So the programmer wants more time to write cleaner code. This is good in that it means the maintenance will be less costly. If you plan on supporting this product or shipping v2.0, then you want cleaner code at the beginning.
If there's no plans to support it or ship a new version, then tell the programmers that.
Once the programmers and the business people clearly understand the real issues, then management is easy.
One thing I've noticed in living with Kubuntu is that it's quite a bit more political than Gentoo. That is, support for binary drivers and stuff like MP3 is significantly more painful than it is in Gentoo, or even CentOS.
I like the way Kubuntu recognized my SATA and iPod subsystems off the bat, and its smart grub configuration system. However, when politics gets in the way of user experience, that's bad IMHO. Perhaps the default should be to install the stuff users expect, but to flag it so that users are made aware of the implications of their choices?
If Gentoo could take the smart bits from Ubuntu (the great installer and autoconfiguration, sensible defaults (where they're apolitical), even the 'root-disabled-by-default' for certain installation classes) while still using ebuild/emerge and remaining somewhat apolitical, that'd be nice.
Also, I've gotten lazy, and I quite like the chkconfig/service stuff from CentOS, so an analog of that rather than hacking S??service files in the init state dirs manually would be nice too... (Maybe I should just go back to gentoo when the SATA situation improves?)
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
So it's more than a mere accident that Opera, with its relentless focus on the Human Interface - and looking after the needs of users like your grandmother - stands set to reap the rewards. Instead of investigating the nerd-options, Opera invested in smartphones and embedded appliances.
Now I wonder which company has the largest browser market share? Maybe that willy waving paid off.
Leadership emerges naturally in any group of people for the simple reason that it is in our nature. The best is to formalize the role of dealer in order to avoid the wasteful bickering that will ensue a situation in which the leader is not clearly defined.
:-) ).
We are primates, never ever forget that, we always look to find the most suitable leader for any situation and immediately start to plot his demise. We need a silverback to protect us and to make the group of monkeys homogeneous, but we hate the silver back because we want to be in his position (and we want to mate also
All this one vote rubish and all the other mumbo jumbo you mention is against the nature of small groups of people, and when it comes to find the best solution to something the point of view of a good leader is more valuable than the point of view of 20 apprentices. Ask any old timer in the IT world how many times he or she has been the reinvention of the wheel and my point should be obvious.
We vote for leaders when human societies grow too big to express interpersonal hierarchies. Any silverback would be executed by the mob without a societal agreement of some kind, democratic or otherwise, but in small groups that is unnecessary, thus it is important to help the group establish a leader so that it can concentrate in getting come job done instead of back scratching and expurgating flease to stablish a proper hierarchy.
IANAL but write like a drunk one.
I found this in the footer of the Shuttleworth post, "This entry was posted on Friday, November 21st, 2003 at 6:48 pm".
What's up with that?
This guy hit the nail on the head. Though it might be simply because these guys bought the party line that you have to use X.
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.
That's only the yang of geek.
There are plenty of geeks out there refining their yin.
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".
In the Russian space program, a person becomes a cosmonaut upon having had a successful space flight. In the U.S. space program, an astronaut is someone who has flown above 50 miles in altitude. So paying a bunch of money is a valid way to become either.
Zope is a good technology choice for this project. And SchoolTool is a very neat project indeed. I always thought the world lacked such a product.
But no matter what technology and what sort of software you're building - be it OSS or not - you need a plan how to do it and should stick to that plan as far as possible. That's the lesson he learned.
We suffer more in our imagination than in reality. - Seneca
Nono, that's good. It means it'll be another two and a half years until the dupes start getting posted.
Good leaders who understand the limitations of technology exist, The problem is getting geeks to find legitimacy in a manager who is not a geek too. In a nutshell: forget it.
Software is not supposed to be about how to work around a useability issue. - Ken Barber
The answer is GEGL, a non-existant "shiny geek toy". GEGL is supposed to be some amazing framework that will handle image operations the Right Way. It will make 16-bit color, CMYK, and adjustment layers appear by magic. It will be fast and generalized and light-years beyond anything Adobe has and wash your windows for you. Who knows what it is supposed to do now? Unlike the codebase of GEGL, the legend of GEGL grows by leaps and bounds.
It you read the gimp devel list archives, you'll see many cases of people saying, "I want to code CMYK", or, "I have 16 bit support". The developers always send them away, "You are doing things the Wrong Way, you must work on GEGL instead!" The result is, development is killed.
What of GEGL? Years go by and it's nothing more a "design document" aka Musings of a Lotus-Eater, that hasn't been updated since the Clinton administration. A CVS repository that goes eight months at a time between commits. No code that actually compiles and does anything. It's still just a pipe-dream shiny geek toy.
Mark Shutteworth tried to fund someone to work on GEGL. I imagine nothing ever came of it.
Is he just bitching for no reason, or has he come up with some new geek toy to solve this problem?
...to "Soyuzworth?"
Any technology distinguishable from magic is insufficiently advanced.
That's classic Java twattery. "Well we didn't build your web application but we did come up with this AOP-maven-driven-frameworky thing which we'll be presenting at JavaOne".
This was 2003. In 2006 this type of project spec is best given to a team that knows wxPython.
I'm not clear on why he's hiring programmers generically and not hiring people whose itch *is* the software he wants. They may not be super hotshot programmers but they've got the right motivations. In other words, enable people that would produce the software already if they could just afford to do it -- so many people have dreams but can't afford to follow them because their day job keeps them too busy. Particularly if you're working in Python the barriers to entry for less skilled programmers are much lower.
I think one solution to this problem is to hire programers who are already interested in solving the problem the program is going to be designed for. For instance, with the school administration program Shuttleworth is talking about, he could hire a group of school IT people who have struggled with the proprietary school administration programs that are out there. I bet they would be motivated, focused, and would come in already having lots of ideas about what needs to be done and how to go about it.
no money, zilch, unless they produce what they were hired to produce. If they fail it, too bad, no check, buh bye!And hire others then. Do that enough eventually you get workers and not jag offs.
With that said, as has been stated elsewhere in this thread, ubuntu keeps trying to reinvent the wheel so they can say it is ubuntu. I've tried it..meh...it's another regular linux distro, nothing special about it. Some stuff works, some doesn't and looks and appearance are taste, nothing special there either. It's earth tones! Who cares. It's shuttleworths hobby, like jay leno collects cars. He's a rich guy, they are used to getting what they want, and in this case it was his "own" distro. I guess geek chicks dig it, nice to drop at cocktail parties, "BTW, I'm an astronaut and also run Ubuntu".
It's not a whole lot different from any of the other 500 debian clones, just gets a lot more press because he had millions of dollars to throw at it. He took debian unstable and ignored the debian slow as mud political inclusion process and also ignored the other 15,000 apps no one uses, and called it a distro, complete with wiki and forums and whatnot. He could have just doled out money to good projects inside debian, and to the foundation, but see, you don't get to own anything that way.
What would have been *interesting* is if he had started from complete scratch, at the kernel and tools level, I mean a completely clean slate, and worked up from there using the GPL license and actually hired and paid good coders and really used some *revolutionary* concepts. There's any number of directions he could have gone, just a debian gnu/linux kludge klone is the easiest. Frankly, I am way more impressed with Knoppix as a debian clone, at least they did something different and it worked, on a very limited budget.
The difference between his example, and most of the Open SOurce world is the "hiring the developers" part.
In most Open Source, you have people building tools for their own needs/desires. Firefox comes from people who wanted a usable browser. OpenOffice, a workable office suite. Linux, a powerful OS.
In his example, he hired random people and threw money at them. "Why aren't they making my school application?!" he cries. Well duh, its because they have no interest in the "School" part at all. If this was some group of developers already working towards a School application, and he decided to give them some money and a list of "requests" I am sure he'd get better results.
Big corporations do exactly that. They fund developers already interested in the OSS application. If they do hire people, they expressly lay out what the company wants from them... and voila! Open Source works.
Next time, don't worry about management and setting up teams and structure for your random develoeprs... just hire interested developers.
Wow, then Time will tell the fate of Ubuntu! So one fine morning when you wake up, you may find Ubuntu is scrapped. Actually, hurd of cows also need a shepherd. Having money to feed them alone is not enough to reach the destination.