March 24, 2008
This classic Eric Lippert post describes, in excruciating, painful detail, exactly how much work it takes to add a single ChangeLightBulbWindowHandleEx function to a codebase at Microsoft:
One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
One program manager to write the specification.
One localization expert to review the specification for localizability issues.
One usability expert to review the specification for accessibility and usability issues.
At least one dev, tester and PM to brainstorm security vulnerabilities.
One PM to add the security model to the specification.
One tester to write the test plan.
One test lead to update the test schedule.
One tester to write the test cases and add them to the nightly automation.
Three or four testers to participate in an ad hoc bug bash.
One technical writer to write the documentation.
One technical reviewer to proofread the documentation.
One copy editor to proofread the documentation.
One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.
Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.
A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.
I think sometimes programmers forget how much work it is to create software at large companies. What may seem like a no-brainer five line code change to us on the outside is perhaps five man-weeks of work once you factor in all the required process overhead. We're picking on Microsoft here, but this is by no means limited to Microsoft; it's a simple function of scale and audience for all commercial software.
So then, the obvious question: who does all those things for non-commercial, open source software? The answer, per a Raymond Chen comment on the same post, is "nobody":
Who develops the test plans for open source software? Who updates the screenshots in the user's guide and online help? And who translates the documentation into Polish and Turkish? Who verifies that the feature doesn't violate the Americans with Disabilities Act or German privacy laws? Back when I worked on Linux, the answer was "Nobody. 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." Maybe things have changed since then.
Here's my honest question: does open source software need all that process to be successful? Isn't the radical lack of process baggage in open source software development not a weakness, but in fact an evolutionary advantage? What open source software lacks in formal process it makes up ten times over in ubiquity and community. In other words, if the Elbonians feel so strongly about localization, they can take that effort on themselves. Meanwhile, the developers have more time to implement features that delight the largest base of customers, instead of plowing through mountains of process for every miniscule five line code change.
Are large commercial software companies crippled by their own process?
If you openly reward and promote people for killing work by bemoaning the risk and the testing cost and localization impact of each feature and interrogating a design change request as if it were Dan Brown shackled in-front of a wild-eyed, hot-poker wielding Pope, well, everyone is going to grab pitchforks and jump on that "No can do! No can ship!" bandwagon.
It makes me think of how many feature meetings I've had and what a small percent of those features have actually ever shipped. Not that every feature is a good idea, but it's damn near wake-worthy sometimes for a feature to actually get out into shipping bits. Que Eeyore: "Oh no. Now we have to support it. I suppose a hotfix request will come in any moment now..."
All too often, it really does feel like Microsoft's software was designed by Eeyore.
In this case, the bird represents features that delight customers.
Posted by Jeff Atwood
All of those processes make it cost prohibitive to do a single addition like ChangeLightBulbWindowHandleEx.
I'm sure that's why Microsoft bundles all of these teensy-weensy changes into one biggy-wiggy push.
For those people who are claiming that they don't understand how Open Source projects can get away with lacking a lot of efforts that they see as essential, think of that clichd cartoon "What the customer asked / What was in the spec / ... / What the customer actually needed".
Given a choice between the price of a typical enterprise installation and that of an open source program that fills the same need, a lot of those 'essential' features turn up to be not that important after all. If you're ponying up $40,000 for your software, you're going to be pissed off if you find out it doesn't support the Uzbek locale because you were planning on extending your business there, eventually. If it comes for free, however, you start realizing that you're not actually doing business in Uzbekistan right now and the entire expansion deal may be a dead end anyway, so you'll deal with that when it happens.
Yup. Been there done that. Nearly 15 years in a CMM level (almost) 3 shop; they never submitted to formal evaluation though.
Then too, I've been paid to develop open source software. I was hired by a big company to work exclusively on an internal project later released as open source. I continued on that project for several years after it had become open source.
In the open source project we did conform to Spolsky's "12 steps" long before Spolsky wrote it up. We also used an Agile process based on first having taken a lot of time to get many (most) of the requirements defined and an system architecture designed. In the ongoing Agile process, there was a significant lack of workflow and formal process. What I believe was key to the project's success is that the work required a very high level of "job maturity". What I mean by that is that the participants had to deal with all the important details of what he was working on in its entirety. I believe this means that the majority of developers on the project were at least in the top 20% of software developers worldwide. Me being the notable exception, of course.
Some of the other things that made a strict division of labor and workflow management less important was the the project was architecturally more sound than some products that come out of many commercial shrinkwrap companies. That means that that our project used a modular approach; low levels of dependencies on other components; adaquate data hiding; and other good programming practices. All these things are artifacts of better and best software developers.
I now do some software development as a "shop of one". The software I am working on now may someday see the light of day as open source, but for now it is for in house (my personal house) only. I use a similar Agile process for implementing features. I use Spolsky's "12 Steps". I added some process from Fogel, "Producing Open Source Software" in anticipation of release as an open source project. I also added some process elements (checklists, automated checkers, test coverage metrics, memory leak detection, ...) from my own experience that help with product quality.
It works for me.
See also comments by Justin; David W;
@Doug -- My own process includes things learned from "Personal Software Process".
@Gunther -- Yes, some OSS projects release software for user testing. The big ones and many smaller projects also develop test suites too. Mine does.
@Peter S -- on "Shadow IT organizations". Sometimes a bad solution is better than no solution at all or an unacceptably long wait for the formal IT organization to get to implementing what is needed.
Maybe this is why the programmers in the zoo don't seem to have as much life as the ones you find writing code on the open Serengeti plains in Africa.
Several months ago I installed Ubuntu. There is so much to love about this OS. However, I had issues finding a driver to fully utilize my Nvidia graphics card. Within hours I was poking around in ugly text files, restarting X, and installing drivers posted on a stranger's personal web site. I was also instructed to take fonts from a Windows install in order to get the display looking reasonable...
Then there are things I take for granted on my Windows' machine...like being able to copy paste from one window to another. If I was using a mix of GNOME KDE applications (or whatever) these things don't work reliably.
Eventually I just became tired of fighting with the system and reinstalled Windows. It just works...mostly. It takes a couple of months of living with Linux for me to start appreciating Windows again.
For the past week I've been playing with Django. Django is an AMAZING framework! I will likely launch a personal project using Django. However, here is the install instructions I was working through:
Notice paragraphs like the following:
"Now that we have Python 2.4 and mx Extensions installed, we can install psycopg. Unfortunately the psycopg devs do not maintain win32 binaries...."
I completely appreciate the person who created this web page, but half way into this I wanted to quit. I miss being able to click "setup.exe" and being done 3 minutes later.
Then came development with Django. Again, I love SO MUCH about this framework, but some of the error messages were almost meaningless. If I forgot to put a "colon" the error would often direct me to something deep in the Django framework itself...instead of the obvious typo that I had made.
I could go on to describe Django's lack of API documentation or that I couldn't find an IDE with robust reflection auto-complete abilities.
All this being said, just evaluating Django has opened my mind and helped me see new possibilities. I have already begun to apply things I've learned to my ASP.NET projects. This is the way it has always been for me. Open source opens my mind to new possibilities and innovations. However, when it comes time to get work done...Windows, Visual Studio and ASP.NET.
you're experience closely mirrors mine. I got so fed up with NetBeans. I installed NetBeans 6, worked with several pre-releaase builds and also the final, and really simple things just didn't work. I was trying to do something simple, connect to one of the world's most used web services (Amazon E-Commerce) and set up a GUI app that has a form for a search entry, a button to launch the search and a table to diplay the results. It was something that I expected to take a day to build.
A similar experience as to what you described: soon I was knee deep in build scripts, trying to install WSDL parsers that were compatible with the java revision and doing all kinds of things like that.
Each little issue I encountered took up a lot of time and none of them had straightfoward answers. Worse yet, they were just never ending! For something so f*#!ing simple!
Anyway, after months (yes, literally months -- ok, not working full time on this) I just pulled the plug on java. BTW: My experiences with Eclipse weren't any better, although not as recent.
I installed Visual Studio .Net 2008 and had this little test project working in the originally anticipated day. Everything just worked as expected.
Again, one thing wasn't the problem, but the fact that it's never just one thing. Every time I got something working, something else, just as absurdly simple, either just didn't work or threw some error or something. I really don't know how they expect anyone to actually program using tools like this.
Hi Jeff, I totally agree with you in this aspect. It's important to see the advantages of each approach but in this case open projects are more dinamic than big companies.
For me it's a lack in OpenSource. Sure, anyone can look at the code and "repair" it. But as you can see, most OS-developers want to add features, not to repair bugs. You can read a lot of this things from developers like Alan Cox or in the Mozilla project. A half developer doing Thunderbird issues? Nobody to fix kernel problems, but a lot of guys to implement new features. That is really the opensource part (and never go to the firefox security newsgroup. It's scarring to see a high priority bug which isn't fixed after a year...)
You think Microsoft are doing all that for fun? They're doing it because their customers demand that it is done, or (for localization) to target bigger markets. Or, given they have a big bullseye marked on their backs now, to satisfy governments. Adding a new function to Windows and not documenting it? Why, that's anti-competitive! (Adding a new feature that duplicates something in the market and not charging for it is also out, which is why Hyper-V is available separately at a stupidly low price, and the cost of Windows Server 2008 without Hyper-V is coincidentally the same as Windows Server 2008 *with* Hyper-V, less the stupidly low price of Hyper-V 'sold separately'.)
The amazing thing, to my mind, is that enterprise customers are *not* demanding that it's done for open-source-derived products.
On my Linuxbox, witch runs almost exclusively open source software, 98% is localized to Norwegian. Security patches and bug fixes arrive daily. Just because there's no fat manager supervising the process, it gets done, there is a plan.
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. Which means: if that process, all that expensive overhead, doesn't guarantee quality, why bother? I mean: if skipping half the overhead results in the same quality, why bother doing the rest of the steps?
And if I may add: the process described isn't applied to a lot of areas apparently. When looking at the vs.net SDK, there are many methods undocumented, and no-one can tell what they do.
I disagree with you on the Quality. Withing an hour of installing Vista, I was up and running using it and installing my favorite apps.
Microsoft has adopted this process because of the lessons it has learned in previous releases. It's not like this process was implemented from Day 1 at Microsoft. It's been put in place to help ease issues caused by security concerns, localization problems, application compatibility, and the like. Microsoft gains revenue by ensuring that all the boxes are checked off. Open Source doesn't care because, for the most part, they don't depend on selling their software to but food on the table.
This reasoning alone is why Linux will never be huge on the desktop. Microsoft's process has evolved to put an Operating system on hundreds of millions of computers. Clearly it works. It's also still working.
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. Someone writes the code, and perhaps the unit tests and javadoc/doxyogen header comments, and all the support people upon seeing the svn commit go and update the localization strings or do whatever it is they do.
However, one thing I've noticed with open source projects is they tend to have better process than closed source projects. When your only collaboration is svn and a mailing list, you make sure your code works before you commit it. When no ones paying you to write the program your writing, you take enough pride in your work to write a unit test.
I can't imagine anyone thinks rigour and quality (good processes executed by great people) is a bad idea.
Is this, then, where commercial OSS comes in?
Alfresco, Zimbra, etc generate cash and can (do?) fund quality processes (quality ain't free) and tap into the pool for 'innovation' as well as grunt work...?
That's a deep pipeline, and it's even deeper than described (who gave the go ahead to implement ChangeLightBulbWindowHandleEx?)
It's overkill for a single feature, but if you think about that pipeline in the context of a project/product/product-line, then it's not as ridiculously unbalanced as presented.
As far as comparisons to Open Source; how many people would be involved for a comparable (localization-requiring) feature to make it into the next version of Mozilla?
Obviously nobody commenting deals with Sarbanes-Oxley regulations. The auditors barely let us get away with having Linux; anything that actually performs business functions HAS to have all of those processes. If we use open source apps, then WE have to do all that work before we put it in.
I think this kind of process is crucial to any software development. It's a pain in the a$$, for sure, but worth it. I've been writing mainframe programs for better than five years now, worked in shops where I could copy my code directly to production myself without oversight, and worked in shops where a change required every bit as many steps as the light bulb change above. In all honesty, I prefer the Microsoft approach. It may be just a little of the "keeping me honest", but it's nice to know that the other developers around here are jumping through the same hoops, that we shouldn't end up with too many programs that can be submitted to the dailywtf.
this says everything you need to know about Opensource
"On my Linuxbox, witch runs almost exclusively open source software, 98% is localized to Norwegian. Security patches and bug fixes arrive daily. Just because there's no fat manager supervising the process, it gets done, there is a plan.
The key words are 98% localised (which is good enough), if no-one uses it in Mongolia then it won't get done, but the Norwegian Linux users want it in Norwegian so they translate what they use... How many Windows programs do you use that don't localise properly?
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."
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).
PS: Jeff, do you think Firefox would still lack the essential features in core if any sane commercial company developed it?
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.
Re: who does all those things for non-commercial, open source software?
Well, I do of course ;-) When your open source project consists of a team of 1...
Two things come to mind as I look at the ChangeLightBulbWindowHandleEx process:
1. Seems like a lot of managers are busy being the bottleneck of process (write the spec., PM after PM, integrate documentation, etc.)
2. 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.
It's amazing anything gets done on any large-scale software project.
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.
Open source development is clearly the winner.
The problem is that the project must be fairly popular to get a community behind it.
These two issues seem orthogonal to me. Yes, big companies have a lot of management to deal with lots of issues like localization and security, and yes, most open source software doesn't. But the fact is, developers don't want to do these things, and if there are people who want or need them, they'll have to pay. The open-source-ness of the code is irrelevant - a company could easily exist around localizing and securing a product like MySQL or Asterisk and get paid for it, if they can convince enough customers that such an effort would be worthwhile.
Yes!! Best article I've ever read on here.
It's important to emphasize (as you have) that these "peripheral" concerns in an open source project are typically handled by third parties - the core developers can get on with adding features or fixing bugs.
Brilliant article.. You've made my dreary day more enjoyable ;)
I recently set up my computer-illiterate Chinese mother-in-law with Ubuntu, her first computer. (complete with explaining all the basics... you have to click in the text box you want to type in, the difference between left and right click and all that... gives you an appreciation for Apple's one button mouse, particularly the new ones which actually have a "hidden" right button to satisfy everyone)
But anyway, it's completely Chinese-translated, with the ability to switch between entering Chinese and English characters. Its native for her, has no maintenance, the computer stays out of her way. Almost as good as a Mac. (considering this was a hand-me down machine, so we weren't going to buy new hardware)
The key is *you* don't need to be a programmer and supplying translations. You just have to be part of a community that has *at least one* programmer, who is inspired to do it for himself and/or everyone else.
Which is why Ubuntu 8.04 will be available in 81 languages:
Compared to MS's 25?
Well the issue here is most large companies that use Windows, expect it to work as is. Most new versions of windows have bugs, but most companies don't switch until atleast a year has gone by so they know its stable, after that they don't want it to become unstable all of the sudden.
Same for oss Middlemen like RedHat or Unbuntu, they wait for the platform to stabilize before pushing it out to customers.
In these cases the Middlemen do all the boring work that the oss doesn't do for its self.
Anyways on a personal level, I dislike the fact that .NET comes with big API changes and no documentation along with every update. Code is supposed to outlive binaries, but in .NET that is not the case.
I'd really appreciate MS to deprecate their code like Sun does for Java.
"who does all those things for non-commercial, open source software?"
Well of course the open source community does :-)
I think its very difficult to compare the development process of Microsoft with the process of an open source community. They differ pretty much in their demands, be it law standards or compatibility issues. This seems to be not least down to the fact that Microsoft has a much larger customer base (See http://www.joelonsoftware.com/items/2008/03/17.html, where Joel Spolsky explains many-to-many-markets). Also Microsoft is watched closely by government and competitors for things like unfair practices etc.
I disagreee with this article. I'm a programmer but now I work in management and it's my job to get things done. Not hunt around source for undocumented bugs, not spend an afternoon looking for documentation that doesn't exist and not upgrading to a new distribution every 0.000x release because nobody could be bothered to test. Programming is fun, bugfixing, documentation and localization aren't so these will always be weak points in open source projects.
You're joking right? There's no such thing. When something goes wrong (and it will) who's going to fix it? You, or her? One of the reasons Microsoft has that huge process in place is so the end user actually has a shot of working out a problem themselves.
Process, here is the thing that absolutely kills me about process. I am currently working in the largest company of my career, over 3500 employees worldwide. I have worked as the second employee of a startup.
We have process, big process. Ours is mostly home grown. No outside tools can enter, because obviously we are smarter than anyone else and can do a better CVS than CVS. (That was sarcasm, for anyone who was wondering).
In previous startups I worked on what had to ship. The productivity ration of startup vs. big company is practically infinite.
On my own, I started working with the Personal Software Process. (http://www.sei.cmu.edu/tsp/psp.html) No one else in the company that I know about (I have asked) uses it. The quality and bug free productivity gains have been enormous. I was doing so well they make me a project lead, so now I manage, not code. No more productive work for me. Sigh.
Here is my question, and point: QUALITY BEGINS AND ENDS WITH THE INDIVIDUAL DEVELOPER. Adding layer upon layer of process and checks on top will not improve bad code. You are putting lipstick on a pig. This may explain the claimed open source advantage so many other posters mention.
A better strategy is to invest in training, keep measurements on quality and productivity, then get out of the way!
But note that each step of adding the process ChangeLightbulb to your system: planning, specifying, coding, testing, documenting, etc., is done by a different group of people.
And all elements in the process are autonomous, independent, and incommensurate-- e.g., how many documenters does it take to 'cover' one coder? No one's on top, no one's in charge. There's no 'Steve' to set standards and priorities.
It's easy (and fashionable) to complain about MS software and claim how great Apple is. However...
1. Apple is also a huge mulitnational corporation with billions in profits and is no kinder or nicer in it's business practices than MS.
2. It's alot easier to make software for only a very few hardware platforms and with a very limited range of peripheral support.
3. Apple make great looking hardware - just look at the Mac Air or IPhone. However, features/$ they are way overpriced! Which is why I am sticking with Vista and a HTC phone for now.
And as for Linux; I recently reinstalled an old laptop with linux (was an xp-machine) hoping for a performance boost. It was actually SLOWER!
"who does all those things for non-commercial, open source software?"
Well of course the open source community does :-)
Eventually. And by the time it's done, does it have the same number of man-hours put into it as the commercial software? The difference being that the day a customer actually shells out money for a product, they expect that work to already have been done, not that someone will take enough interest in the bug/feature/documentation to get around to doing it someday.
In any event, the ASP.NET team has released and is releasing a number of technologies that have been created by very small teams and developed in much more agile ways than what's described here: Web Application Projects, Web Deployment Projects, ASP.NET AJAX, ASP.NET Dynamic Data, IronPython and IronRuby, and (currently in progress) ASP.NET MVC. There's a great opportunity here for people to step up to the plate and provide (e.g.) the vast quantity of API docs whose lack Frans Bouma is noting. (And localize it.)
Do proponents of OSS use only and exclusively OSS for everything on their computer? If not, what's the basis for sometimes paying for software? Surely there are times when paying money is the more convenient way to go. If so, why is that?
Are large commercial software companies crippled by their own process?
Yes--and not just software companies, thanks to SOX. The current path of the US government is going to kill American IT, and with it, American enterprise.
@Rhywun Spoken as a true MS user! Of course MS makes it "easy" for the user to do their own maintenance... except there shouldn't *be* any maintenance!
So far, this machine has had *zero* maintenance issues. Of course, she's not pushing it too hard either. ;) But that's the point isn't it? If you're not mucking around, the machine shouldn't break.
Once you no longer have to worry about spyware and viruses, don't run as administrator so users can't accidentally break things, and have a good package manager to handle updates for you (and avoid conflicts and configuration issues to boot), you'd be surprised how little there is to do on the machine itself.
If the world's number #1 developer of Operating Systems, application suites, and developer tools is a donkey....
What does that make everyone else?
Almost all open source software worth its salt comes with tests.
There might be less formal process involved, but having multiple people writing moderately sized software without tests is near to impossible.
I think the advantage of open source vs closed source isn't the lack of process, it's the addition of passion. People working on open source are scratching their own itch.
Wait Microsoft has user guides?
A quick check of the couple of products, Vista, Office, VS2008 and a few others had nothing but at the most a tiny booklet on installing. I have more informative read me files from the most recent USB flash drive I purchased.
As for online, excluding marketing material, most of that is text and most of the really good stuff is in the blogs and other places that are not translated. If you want to check find a text area translate it to another language to get the general text, switch to the google site for that language and enter some of the key words and see what you get.
Many OSS projects in effect conscript their users into the development process -- the users effectively are the testing department, the usability consultants, the project manager setting priorities, etc.
There's still a process, it's just very ad-hoc and undependable in many cases. Although, there's always a risk that the process can be more of a hindrance than a help, if your livelihood depends on customers purchasing your product, you generally want to have a little more control of your development process.
I've been fascinated recently by the concept of a "shadow IT organization." This is an informal group of power users inside of your organization, functioning in IT-related roles, but not inside the "real IT" organization.
The correlation here is that in the scenario above, the real IT organization failed to meet all the needs of its customers, and so its customers formed shadow IT organizations. You've seen Access databases and Excel spreadsheets and even little VBScript scripts and (sometimes) PHP-based websites running off of desktops.
What I've often found with "shadow IT" is that they often do a terrible job of building solutions. I've seen unsecured sensitive (or valuable) data, "disaster-prone" solutions with no backups, and worse: ACCESS DATABASE "APPLICATIONS"! Inefficient (and unnecessary) manual processes. Auditing nightmares. Constant maintenance nightmares. A high "bus factor"--i.e. if the shadow IT employee quits, all these things will cease to function!
What's been fascinating me most is this: given the AWFUL QUALITY of "shadow IT" solutions, why do the departments bother at all? Why not go back to IT?
And Jeff, you've (reprinted) the answer: we're drowning in process.
Even if the extra processes add quality and result in a better product, our users continue to build awful solutions themselves. So how can we make it easy and cheap enough that our clients actually start working with IT again?
If you want to see a well managed gigantic open source project (including usability, localization, internationalization, and even marketing) you should see KDE.
I think you'll find Planet KDE (http://planetkde.org/) interesting even if you're not a contributor (I'm not, yet).
I still don't get the Eeyore thing... what's the donkey about?
Qu? Significa "cue", no?
(I too am super-confused by the presence of that donkey.)
One thing that seems to be happening to me is that smaller, nimbler Microsoft teams do all the code writing, maybe generating some decent docs using inline comments, and avoid all that process. They publish their work as "technology previews" or some such. When it's time to roll the stuff back into the main product, or publish it "for realz," then---and only then---does the overhead have to be processed. A sort of delayed execution, if you will ;).
Is this at all accurate?
A lot of the formal (boring) processes you're describing are required to create "polish".
I can certainly appreciate the incredible innovation of the open-source community. However, much of that is "skin deep". The deeper I get into the project, the more I want good documentation, easy installs, modern IDE's, good integration, etc, etc.
I would love to be one of the "cool kids" and use open-source. However, I find I am often FAR more productive using M$. :(
Working at a big company, I certainly see the drawbacks to the process, up close and personal. And yes, lots of bad decisions get made. Open source development leads to a more JIT process for solving the issues that the process tries to solve, but because of this it isn't very highly adopted in the money making markets (consumers, enterprise, etc.). Consumers try it, find it doesn't work for them (usually because of some small thing), and then go back to what does work. Enterprises quickly recognize that they need to hire a bunch of experts and programmers to make the OS products work the way they need it to. Sometimes its just easier to pay a big software company a ton of money to do that for you.
In both markets you have people willing to pay for a better experience, and they can get it. Open source works great in markets that expect low cost and are willing and able to deal with the inevitable issues that arise.
There's a stereotype about open source developers and software that it is hacked out by a bunch of loser geeks who can't hold real jobs. That the software is sloppy and has never been tested.
Open source covers a wide range of software. In larger projects, many of the developers are paid to work on the project. For example, IBM has a whole group that does nothing but work on Linux. Google encourages many of their employees to contribute to open source projects on company time, and several people in Google actually lead major open source projects. And, this doesn't even touch on Google's Summer of Code.
Even Apple is into the act. Many of their employees work on BSD and of course, WebKit. Which brings us to the Mozilla Foundation and FireFox. FireFox is open source and is heavily supported monetarily by Google.
You can look at CollabNet which sponsors SourceForge (both the "open source" version and the Enterprise version) and Subversion. Both of these open source projects have paid development teams, but are also open source.
These are all open source projects, but because many major corporations depend upon it, they are happy to contribute time and money to see these projects through. Look at Google's Summer of Code. (And Google actively encourages all of their employees to contribute heavily to various open source projects).
Many open source projects are headed by a small team who get paid by their company to head the project (just as you would any proprietary open source project). CollabNet is the sponsor of the Subversion project and has several full time employees overseeing the project and probably contributing a good majority of code.
Then there are projects like PHP.net and Joomla. These don't necessarily have large corporate sponsors, but what they do have are dedicated development teams that heavily depend upon these projects. Maybe these developers don't get "paid" to work on these projects, but they do get paid for their work that is based upon these projects.
So, many open source projects are fully tested and well documented -- even better than most commercial software. The quality difference between proprietary and open source software is small. Yes, there are many hacked together open source projects with poor documentation, few software options, and barely work. But, that also describes about 80% of the commercial software too.
That is an depressed donkey from a child comic.
MS does all that?
With their quality of code I assumed Bill Gates does the "Works on my machine" test and puts it in a hotfix.
Quoted from David w.
"There's a stereotype about open source developers and software that it is hacked out by a bunch of loser geeks who can't hold real jobs. That the software is sloppy and has never been tested."
David, that certainly isn't my impression. My impression is that open-source software is created by people who are [often] very talented and passionate about technology the problems they are solving.
All of this is really awesome and this is why innovative trends are often created in the open-source community.
However, writing documentation, management tools, a nice install program, an IDE, etc. is far less "sexy".
When I use open-source I "feel" like I'm on the bleeding edge. It can be really exciting and it can also be infuriating. Trying to compile the latest greatest and fight my way through library dependency issues....
Maybe I'm getting too old (31) but I'm finding I just want stuff to work....
I think my point may have been missed.
My belief is that all of these TASKS (with the possible exception of the last one) are NECESSARY in order to ship software at the high level of quality that my paying customers rightfully expect.
* How is the source code is managed?
* How are the people who provide the effort to perform these tasks coordinated?
* How are their efforts are rewarded?
* How is this process implemented?
and so on are interesting questions, but irrelevant to my point. All these value-producing tasks require _effort_, and effort is not free. There is only a finite amount of effort available in the world, and effort spent on endeavours which produce little value are consuming effort that could be spent on high-value efforts.
You ask the question "does open source need to take on this process?" No, of course it does not. Have any process you want. You'll either (a) learn to live with low-value software, or (b) come up with some system whereby someone's effort is turned into value. What that system is, again, is a good question, but entirely orthogonal to my point.
You then make a straw man argument, implying that Microsoft developers are mired in process. _I_ am not mired in process. I design and implement code all day. Some process-loving wonk owns the process, and if they are unable to make that process invisible to me, I complain to them until it disappears. Microsoft spends huge amounts of money ensuring that developers like me are able to be productive doing what we do best. It would be stupid to make talented people do what they are bad at.
And finally, delighting customers does NOT mean trying to please everyone who comes along trying to get me to do work for them. It means doing careful research into how customers actually use the product, how their productivity could benefit from changes to the product, and then carefully making only those changes that do the most good.
It may well be the case that Microsoft is bad at saying yes to features that delight customers. We are not perfect; imperfection is the price you pay for working with imperfect people. And, if that happens to be true, it may well be that the _reason_ for our failure to delight is our imperfect process.
But it is surely a non sequitur to attribute the potential failure of our process to produce value to the simple _fact_ that producing value requires effort by a great many talented people all working in concert.
That's all I was saying: that producing value takes effort, and writing the code is a tiny amount of the effort. You either live with low value, or you find some way to obtain the effort.
I am committed to providing high value to my customers, value which _massively_ exceeds the dollar cost that they pay for my software. My part of that is in the design and implementation; but as an organization, we know that the design and implementation are only a small part of the total value prop. My collegues are committed to providing that total value proposition to my customers, and I would not have it any other way. I like working in an organization where I know that these balls will not be dropped.
So far, this machine has had *zero* maintenance issues.
I'm hardly a "true MS user"--I was a solid Mac user for 2 years recently. I've played with Linux many times over the last 10 years. I program on Windows at work, but I've done programming on lots of platforms. Maintenance is not just anti-virus. It also means finding your files, dealing with crashes, looking for help files, and so much else that's part of the daily routine. Unless the Ubuntu box has one button that does something really, really simple and is disconnected from the outside world, your claim of "zero maintenance" is simply not credible.
That was a great post!!!! I'm showing it to my PHB.
He will be happy that I am able to make code changes to our website in a mere couple of hours, rather than weeks(?).
He often complains to me that simple changes take so much time.
So can we assume that Jeff's start-up is primarily using open source?
And so it begins...
I second the point that successful Open Source projects are "agile" development, and have been since before the term existed. Big organizations often use outdated tools and practices, and compensate by throwing more bodies at the problem.
There is also a viscous circle effect with proprietary software - the longer it takes to roll out new versions to customers (because your update technology sucks, or your licensing forces repurchases, or whatever), the more checks and procedures get added, and the more effort has to be diverted into maintenance of outdated versions, and the whole process become even more sluggish. Apple seem to be the only big proprietary software vendor that can upgrade a significant proportion of the deployed copies of their product anywhere as quickly as an OSS project.
You forgot one item:
- One Microsoftie with a complete lack of style to oversee the design, UI and overall implementation.
"Anyways on a personal level, I dislike the fact that .NET comes with big API changes and no documentation along with every update."
You mean this?
"I'd really appreciate MS to deprecate their code like Sun does for Java."
Lots of Microsoft code is deprecated. Can you elaborate on this?
"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 think the advantage of open source vs closed source isn't the lack of process, it's the addition of passion. People working on open source are scratching their own itch."
The problem is, the developers have no reason to scratch an itch that isn't bothering them. A great example: https://bugzilla.mozilla.org/show_bug.cgi?id=339293. I encountered this bug a year ago while working on a commercial web application. I pointed out to my boss that the problem wasn't in MY code, but was, in fact, a known FireFox bug. His response? "Well, find a way to make it work - we don't want our users to have to deal with this." So a MOZILLA bug became MY problem.
I was able to build a workaround. But I notice that this particular bug remains listed as UNCONFIRMED by the Mozilla community. This is one of three rather serious problems that I found in FireFox that no developer in that particular OS community cared to address.
I think we would all agree that TOO MUCH process is bad for development. But too LITTLE process seems to result in a chaotic system where problems such as this are ignored because nobody takes an interest in resolving them.
It all coems down to money... at both ends...
1) If I have to pay for it, I want it to work, have been tested and be documented
2) Testing software, and translating it etc etc, costs money, so you have to chrage for the software.
If its free, I don't expect much, because I want it now, not in ten years time. And I understand that.
The larger a company gets, the more time it must spend in internal communications to make sure everyone's on the same page.
The lesson I learn from this is that leadership in small groups who remain focused on solving problems is more important than process or lack of process.
The good open source software and the good closed source software share this tendency: small groups, engineers unhindered by unnecessary complication and bureaucracy, strong leaders and clear goals.
MS is becoming increasingly unable to navigate its own processes.
Sadly, it is now about as nimble as a mountain trying to tip toe, and in the wake of all the lawsuits, it does not seem likely to get better before or after it gets worse.
Maybe it really is time for MS to break itself up, if only to get a little bit of its flexibility back.
Gosh, it takes almost 50 people to make a change in coding. The way this is worded makes it sound a little sensationalistic; since all of those 50 people are likely working on many different changes and projects. Maybe this boggles the minds of people who work at small tech companies or startups, but consider the massive differences of scale and amount of code being dealt with (not to mention complexity of said code).
After all, we are talking about a huge company with many many thousands of employees all over the world. Everyone knows that larger companies tend to be more structured -- it's because they have to be. That's how you deal with things on a huge scale, not by flying by the seat of your pants. (That would just result in lost money or problems down the road) It's not surprising to me that even for a tech company, size changes the way they operate.
Yes, structure does impede flexibility in some cases... I think it's a matter of finding a workable balance between the two, and Microsoft has many areas where there are a lot of new projects and experimental code (just look at Live Labs for example) being produced. You could argue how much it impedes their flexibility, but not about the necessity of structure at large companies, I think.
Anyone who thinks there's no bureaucracy or overhead in Free Software development has clearly never been involved in it.
If you have any users, you *have* to have good up-to-date documentation, or you'll spend all your free time debugging users issues for them. If you have multiple developers you have to have some kind of updating and build process. I guarantee they'll start reviewing your changes before running with them after the first time you introduce a bug on them too. You'll certianly want to review submitted changes too, as you're the poor sap who will have to maintain it and fix it if it doesn't work. Once you get more than a couple of co-deveopers, you'll need some kind of mailing list to keep things coordinated. As things get larger you start to get things like release schedules and roadmaps, test suites, elected repository managers and release coordinators, appointed feature managers, etc. The GCC devs even make you sign a freaking legal document before they will accept sources from you.
If you don't believe me, surf over to the Mozilla development site at http://www.mozilla.org/developer/ and poke around a bit. To save you a bit of time in the laberynth, their development calendar is at http://www.google.com/calendar/embed?src=pdighgf028nmbjbrno8oed8vsg%40group.calendar.google.com . Note the *three* different weekly "status meeting"s.
I was able to build a workaround. But I notice that this particular
bug remains listed as UNCONFIRMED by the Mozilla community. This is
one of three rather serious problems that I found in FireFox that
no developer in that particular OS community cared to address.
Are you telling me you've never had an unresponsive closed-source vendor? The last time you found a bug in Internet Explorer, how long did Microsoft take to fix it?
There really isn't a lot of difference here. The main one I see is that if it really bothers you, with the Free Software you can go fix the bug yourself (or pay someone else to do so). With the proprietary software, you are generally SOL.
OK. There's another difference. With the Free Software, you can also go poking around the sources to discover the exact parameters of the "bug". This not only helps you figure out exactly what triggers it, but it helps immensely in developing a work-around.
Actually I'd debate that the process is true of all Microsoft products particularly the first generation ones aimed at businesses only, especially those with a small development team. I'm sure it will be true of the mainstream products though.
As far as languages are concerned you only need look at Vista SP1. Correct me if I am wrong but I could not update my Vista machine since it had the Norwegian language pack installed. I needed to remove it before SP1 could install. In addition to this, when has Microsoft ever released UK English version of its software? Firefox has a UK version.
"The problem is, the developers have no reason to scratch an itch that isn't bothering them. A great example: https://bugzilla.mozilla.org/show_bug.cgi?id=339293. I encountered this bug a year ago while working on a commercial web application. I pointed out to my boss that the problem wasn't in MY code, but was, in fact, a known FireFox bug. His response? "Well, find a way to make it work - we don't want our users to have to deal with this." So a MOZILLA bug became MY problem."
Deja Vue: have you EVER heard of IE 6? Of IE 7? MS screwed over so many users it's best not to try and count. Have they bothered to fix anything yet? Have they in fact tried to correct THE PROBLEM THEY are responsible for BUT WHICH IS MY PROBLEM?
I'm sorry for the caps but what you wrote is simply not something you can blame OSS for alone. I don't even think there's a bigger chance that MS will fix things faster than Mozilla given that everytime MS looks at a problem they shudder in their pants because it's another potential disaster waiting to happen - e.g. will break code.
"In addition to this, when has Microsoft ever released UK English version of its software?"
Why would we encourage that? It's time those Brits learned to speak proper English! vbg
For some reason, certain Linux packages like GCC come with "testsuite" which you can run and see the results are the same as expected.
I love the Eeyore comparison
I found this amusing:
"At Microsoft we try very, very hard to not release half-baked software."
My god its so true with any company following CMM Level 5
What kills me from the OSS people is the argument (advanced in this thread) that MS only does certain things for legal compliance. This has 2 implications: OSS folks are scofflaws who are too high and mighty to have their pure hacking encumbered by laws and regulations; and OSS folks do not care one bit about the users for whom those laws were put in place (disabled, old, foreign, etc).
did you forget the install program?
It's interesting that people like to set commercial and OSS against each other when really they coexist quite nicely. It's like arguing which is better, the 5-star steak restaurant or the hotdog cart vendor on the corner, when actually they both fill a need for different people at different times. While there is a vocal minority at the extreme ends that refuse to acknowledge the other, thus making them basically the same types of people (closed-mind fundamentalists) most people, the silent majority, use both types of software on a daily basis without any breakdown or psychotic episode.
I think OSS is a great place to innovate while the commercial software model is required to form a workable relationship with a "paying" customer. I think an OSS project is the first step in the Software Engineering Life Cycle of a truly excellent software product.
I'm not current on the examples but RHEL and Ubuntu's LTS versions come to mind even though the latter is not a paid for product.
One advantage to open source software is the mentality of "Do one thing and do it well." Instead of all the features being coded in one application's codebase they're spread throughout a few apps and then used behind the scenes by other apps due to their open nature.
Jeff - I hate to say it, but I am drawing parallels between this and Paul Graham's essay about You Weren't Meant to have a Boss. At least parallels in the context of what Paul MEANT to say, which was that developers' creativity is sometimes stifled in big companies, and he believes that hurts developers. You are teetering on that edge of developers having features nixed in large companies because of having to support them. I read that as creativity being stifled in large companies.
The arguments are not the same...and you do a great job of presenting facts for what you are presenting. It also seems you don't have an ulterior motive.
Microsoft is making _API_. After they publish it, they'll not be able to change it freely and will have to support it forever, unlike smaller or opensource projects.
Multiply this by factor of their ambitions and cost of a failure. They want to make software which is available to virtually every country in the world, but they cannot afford failures (e.g. which are concerned with some country's law) -- fixing may be very not cheap. Unlike FLOSS, which usually comes with no guarantees or responsibilities.
Microsoft is anything but stupid.
The amount of steps in a process is not as important as having a process with steps. If I can produce computer programs with a process that has two steps 1) "Program" 2) "Ship" then there is no reason for me not to use that process. But it takes more than two steps to produce software.
Lots of programmers' time goes into wondering about things like how they should do line breaks, string building, date and time formatting, etc.
Here is about line breaks. They have pages of posts about what opinion each one has regarding about line breaks:
After that think about more complex issues. Everyone does things differently, because they hand craft the software. Then other people have difficulties to know what every one else wanted the code to do.