It’s not the process that takes the time, it’s the endless rump-kissing and ego-stroking that makes a lot of commercial software less than nimble. For open-source, the participants reward is finished usable code and the affirmation of happy users. For some in corporate, the reward is more immediate, affirmation by one’s managers.
Think of us as the social primates we are. Open source attracts, and rewards intangibly, those for whom the new tool, usable code, is reward. Commercial attracts those who seek a different sort of affirmation, the grooming and community of meetings and nit-picking. Having worked in a corporate environment, ego-stroking people to get permission to do something useful took much more time than it does in the federal research facility where I work now. The needs of the people here are different, the goals of many are to produce useful products, not climb the ladder. There are still plenty of boxes checked, but the output to ego ratio is a lot higher.
I agree, but you’re missing something about devs. I’ve heard a similar statement before (comparing them to Marvin the paranoid android from HGTG).
You want engineers to be pessimists (just as you want sales to be optimists). The person that writes good code is also one that worries about all the things that could go wrong, and tries to account for all of them.
The trap of layers and layers of process is all to easy to fall into, and I suspect the cause is lots of people seeking control, rather than the negative outlook of the front line. I mean how many people in that MS process had manager (in some form or other) in their job title? How much management would actually be needed?
The lack of over management has done wonders for the open source community. It lets developers do what they do best, and after a project has reached a certain level of maturity, the business types come in and clean up the process. In the end, I think this will be one of the key reasons open source software will eventually take over.
"The only justification for all that overhead would be if the quality would otherwise suck. However, looking at cruft like Vista, I can only say: the process doesn’t guarantee it doesn’t suck."
Frans Bouma
It’d be interesting to read a post about how Apple do things. I imagine they have a very tight process like the microsoft one, only more so. I’m not too sure about testing for bugs, but when it comes to seamless integration with existing functionality, Apple are way ahead.
Perhaps the lesson is that if you try to take this route of managing everything in the roll-out to a minute level, you’d best do it incredibly anally, and be the ultimate control-freaks (as I imagine Apple are), otherwise it doesn’t guarantee the benefits.
It seems to me like OS software is elitistic - target customer is english speaking semiprogrammer, without any disability, which eliminates about 95% of world’s customers.
And 95% is also a ratio of commercial OSes on desktop to opensource ones. Because my chinese grandma doesn’t want to translate her programs, and rewrite them to fit to chinese environment, and it isn’t her job.
Yes, OS is good on servers, because its target group is there, but keeping the same approach on desktop and trashing about how unfair MSFT share is, that’s asking for a free lunch if you ask me.
And customer no. 1 for operating systems - companies. They surely don’t want to localize or patch their tools, they are supposed to get the work done with them!
So, in summary OSS would like to be on every computer, but it is completely ignoring its potential customers - how that could ever work? 90% of software development is hard work, but if you let developers choose, everyone will do the 10% (and then boast about how they have more features than everyone).
I think this is the reason that 95+% of open source software has not gone “main stream”. For those that have gotten main stream attention, you will always either see corporate backing (think IBM using Linux) or some other sort of “with it” organization (think Mozilla) to ensure the bugs get logged and worked, the documentation gets written, and the software gets tested.
I once tried to build a Linux MythTV box from scratch. Putting together the Linux box and getting it running was mildly painful, but certainly doable for a computer engineer. But I gave up on MythTV itself after trying for 2 weeks to get it configured correctly (I proved the video hardware setup itself was working by using mplayer on the command line). The software was just too unpolished when things went wrong (window disappears, cryptic error messages on console) for “main stream” usage. Mailing lists and forums were generally unhelpful for support–I gave up on them, too. I found freevo and other simmilar efforts to be even less mature as far as docs and support.
Don’t get me wrong, this is by no means a blanket statement. There are companies with all kinds of process who can turn out crap software, and there are plenty of gems in the open source world. But sometimes, it’s good to have some solid documentation and a dedicated support e-mail or phone number when things go wrong.
“There is no test plan, there is no printed user’s guide, what little documentation there is exists only in English, and nobody cares about complying with the ADA or German privacy laws.”
Lemme see: if MS doesn’t document it in non-english languages, or doesn’t make it comply with ADA or .de-privacy, then they get their butts sued by various “interest groups” or “lobby groups”.
It’s the american way. Who is there to sue with OSS? Dont sue it - add to it. You can’t do that with closed software.
If you look at Microsoft’s earnings reports, you can see why they have no incentive to change this process. If I was in control of a business generating such a terrifying amount of cash, I would certainly subscribe to the ‘if it ain’t broke don’t fix it’ school of management.
Two things come to mind as I look at the ChangeLightBulbWindowHandleEx process:
Seems like a lot of managers are busy being the bottleneck of process (write the spec., PM after PM, integrate documentation, etc.)
And once they’ve all done that, the usability people throw out the suggestion that the ChangeLightBulbWindowHandleEx should actually be a ChangeLightBuldWorkQueueItem.
I was thinking about this one the other day - http://caseysoftware.com/blog/a-foundation-or-an-anchor - at some point your codebase becomes so big/bloated/complex/etc that it becomes a liability instead of a benefit. Unfortunately, it may need to be one due to the problem(s) you’re solving, but it’s still a bad thing…
What can I say its the trouble with Bureaucracy just like in politics as more people become involved and there are more interested parties more work is needed and more time wasted. I think the problem is the same for any large company.
A point about documentation is Microsoft has a large base of mature code meaning every small change is documented at the time of writing which is very slow as each person has to find the code piece check it and so on, it isn’t a very flowing process.
If you look at a mature project with little or no documentation and document it all in one go you will be able to write it in 1/10th the time it took microsoft to write there documentation.
“For more popular and successful open source projects all the issues discussed above are taken into account. Granted, many of them are taken into account after the fact… Justin Dearing”
This is the essence of the problem with open source projects. The quality control work only gets done for the most popular projects, and only AFTER the fact. Then it has to be done again in French, and Norwegian, but only if someone in Norway is interested in doing it and has enough technical skill to do it properly. Estonia may be left out in the cold completely.
There is a place for both groups in the software eco-system, because each one has different strengths. But ultimately, if the software doesn’t work correctly, the consumer won’t care whether it was commercial or open source; they’ll just abandon it.
I, for one, am glad to hear that Microsoft goes through all this. When so many people have to rely on your software to get business done, a little bug here or there can damage the economy (in time lost), not just make you look bad.
Personally, I am glad not that many people use the software we write. Not that I want it to lack quality, but it just does not have to be used in such a wide range of circumstance, so such a wide range of testing is not necessary.
Once your audience is “everybody” you have to please everybody. If your audience is “open-source fans” well, you don’t have to be so strict.
I recently looked back at the “cathedral and the bazaar” and Raymond’s conclusion that open source succeeded in the face of waterfall development (another name for his cathedral) because “with enough eyeballs, all bugs are shallow”. I no longer believe that to be the case. Looking back now, I think Linux, Apache, etc succeeded because they were the first agile projects, even if we didn’t use that term then.
The assumption with the example here, and all waterfall methods, is that without that quality would go to hell and chaos would reign. This is a false assumption, and many times waterfall causes more true quality loss than it saves, when you measure quality from the user’s perspective and not a statistical code-coverage view, or “all unit tests pass”.
Eeyore thinks hotfixes are a measure of quality, and that’s were Eeyore is fundamentally wrong in his view of the quality of software.
Everyone is saying that bureaucracy is slow… it’s supposed to be slow. OK, kids, back to the Cathedral and the Bazaar.
Big companies need these layers upon layers to slow down inertia. Although this kills good ideas, it equally kills bad ideas (which would probably have a net effect over the goodness that doesn’t see light) before they are implemented (sometimes poorly, at that). We can look at this model as a counter to the Peter Principle; those who are managing the technology don’t understand it, and have been elevated to their level of incompetency. You don’t want them being able to make a decision and execute it easily!
OTOH, the open source community is coming from the opposite direction; everyone has a say. If your idea sucks, chances are that the majority of the community is going to call you on it. Everything is based on technical merit (well, in a perfect world) and less on politics, so there is no need to slow the inertia of everyone pushing in the same direction. The net result is that everyone moves as the sum of the parts. If I decide to implement something stupid, I can; but it will only have as much velocity as the number of people who support it - probably not many.
The structure also provides its own maintenance; the community approach means that a new comer must prove themselves (usually doing crap work like documentation and code clean up - check out the Linux Kernel Janitors or Kernel Newbies for examples) while at the same time getting exposure to a massive code base. The advice that is always given if you want to start working on an open source project is to pick an obscure bug and fix it… you’ll cover a lot of code base in the process.
Checks and balances, gentlemen. Checks and balances.
I’ve come to expect a lot less from open source over time, I’m afraid to say. The more I try and use it, the more I’ve come to think that the quality is sketchy at best.
Oh, VLC media player. Everybody says it is great. Except it can’t seek at all without crashing. And it’s been like that for, what, months? Has nobody noticed? Do the devs just think that being able to find an arbitrary point in a video is unimportant? Because it is important. It’s not a special request. It’s a key feature. They should be embarrassed. Mortified.
Oh, OpenOffice.org. You’re supposed to be the replacement for big bad MS Office, right? Except you duplicate all of the nasty things Office does, but do them slower, and uglier. You’ve somehow managed to make Microsoft Excel look like an excellent program with excellent graphs. You’ve made me think that Microsoft Access is a rationally designed program rather than the hunk of junk it really is. Hey, why improve on a bad product when we can just ape it?
“add to it. You can’t do that with closed software.”
WRONG! Yeah, you could, but in most cases, that doesn’t happen. Plus, “real” software companies listen to customer feedback, bug reports and such and addresses them, because that’s how they keep selling their products. This is one of the most bogus reasons ever to use OSS. I’d love to see real and unbiased data on how many OSS users actually edit source code and submit changes, other than for a handful of large, well known projects.
Foolishly, I once thought that OS software authors actually cared whether anyone else was able to use their “product”. yet, when an issue is reported in an OS project, the answer so often is what you said “well, you can just get the source and fix it”.
I got so sick of “well, it works on my Linux box, I never tried it on Window$”. Again, foolishly, when I used to see “our project does X” or “our projects runs on X” on an OSS web site, and expect that some actual testing had been done or some kind of actual validation stood behind those types of statements.
I’d love to have back all the hours I wasted because I actually believed OSS would be a low-cost alternative to commercial software. It’s just the opposite, I’ll never get back the hours I wasted trying to get OSS to work.
If I use software for something I actually need to have working, I want someone to take responsibility and actually stand behind their work. I can’t rely on something where every bug report is treated with condescension or apathy.
When your open source project consists of a team of 1…