What business can NOT learn from Open Source

2005-08-07

Paul Graham recently posted an article entitled "What Business Can Learn from Open Source". I usually like to read what Paul Graham has to say but this time I think he really missed it completely.

He claims that amateurs in the form of open source developers and bloggers are showing that businesses and pros are not the right way to make stuff. He goes on to mention Firefox as one example. The problem is Firefox is not made by amateurs, it's made by paid employees, it just happens to be open source. So is Apache, MySQL, PHP, Perl, CVS, Subversion, Open Office and probably most other high profile open source projects. Maybe the gimp is made by amateurs?

I might see his point with web writers vs. professional journalists but he has nearly zero evidence to back up his software claim, and even amateur writers vs. pro, since the pro is paid and has 8+ paid hours a day to do nothing but write I think the pro is still more likely to do better than the amateur. I think the bigger lesson to learn is the cream might rise to the top in the new environment but they will go professional at that point. Like that Jason Kottke guy, he's now officially a pro, no longer an amateur. Otherwise talented people will get offers making them pros. The real lesson is that without the old barriers talent will rise to the top.

His whole work at a home thesis is so far off the mark as to be laughable. First off he's basing it back on this false open source claims. Then, well, I guess this is just my own belief but the number of people I know that can function at home seems like about 10−20%. The other 80−90%, myself included, need the office to separate work and play otherwise they will play and play and play or procrastinate, procrastinate, procrastinate. They also need the communication and the friendship/companionship that comes from working with people at work. I guess later he talks about startups so if he's saying 10 guys in a room is better than a company of 1000 people with lots of formal bureaucracy I agree with that but is claim of "And yet people working in their own homes, which aren't even designed to be workplaces, end up being more productive." is pure bunk. There may be a few isolated cases but it's not in any way generally true.

He also goes on about fully flexible hours etc, I think it's the rare team that can handle that. I know plenty of people that complain when a co−worker isn't there as late as them. They hate being the only one there. They hate being the one feeling like they are working the hardest. Of course I would personally feel guilty if I thought I was working less than the others but I think basically having too flexible an environment eventually leads to a negative feedback loop (hey, that guy is only coming in 6 hours a day so that's all I'm coming in... That guy then sees another guy taking 2 hours lunches so he starts taking 2 hour lunches. That guy then is seen browsing the net a lot so the other guys start browsing the net a lot, etc.). It's great when everyone is on the same page but even then, I know startups where one partner has a wife and baby and another doesn't. The one that doesn't is working till 12am, the one that does leaves at 7. In the beginning they think it's all okay but eventually it leads to resentment. One thinks he put in 30−50% more work than the other. The other thinks he did the best he could reasonably be expected to put in therefore he deserves the same.

Paul mentions meetings being a problem and I get the impression that maybe he's never actually worked on something large enough that it needed a team. I don't know his history but for example I've written a few things by myself, especially web related stuff so if Mr. Graham made similar programs he didn't need a team and therefore doesn't understand why you have to have meetings. In a game for example where it could be 8 to 250 people meetings are there to discuss design and decide what to do and how to do it and it basically isn't likely to happen any other way. Having one dictator at the top generally does not work. Sure there can be such a thing as too many meetings but zero meetings on a team project is not a team.

Paul talks about walking around contemplating as 50% of his work and that he'd feel guilty for it at an office but it is work. I agree with him that it is work and that he's self disciplined enough to putz around and still actually think about work is great but I know I'm not, sometimes I do need to think about stuff but I also know that if I go for walk or out to a restaurant or shopping or something thinking I'll be cogitating the solutions to my current problem at work that I really and truly will not think nearly as hard as if I just sat at my desk and forced it out. In fact, many self help books talk about just starting, don't think too much, just start creating or solving, figure out one thing you can do right now even if you don't have the complete answer and do it. It's in the work/creation that you'll figure out the rest of the solution, not looking at your belly button relaxing hoping inspiration hits. Does inspiration hit outside of work? Of course. But I'm far far more productive to be at work working on something they just spending 4 hours a day waiting for the inspiration before I do anything.

Paul says "The basic idea behind office hours is that if you can't make people work, you can at least prevent them from having fun". That's a pretty cynical view. Again this goes back to the kind of work maybe. There is 100% creative work, then there is all the busy work that has to be done. Again, I'm from games, 10% or less of the time is coming up with a character and his moves or a setting and it's props. 90% of the time is spent actually making those characters, moves and props and it's mostly just busy work. It gets done directly in relation to the time spent doing it. I'm sure the same is true for most projects. When I made Thumbs, it took a couple of days to of "creative" work to get the basic functionality working. Then it took 2 or 3 weeks to do the busy work of adding an interface and options and another 4 weeks of more busy work writing docs and making a website. That's what "work hours" are for. Someone has to do that busy work.

I guess the last half of his post makes some more sense. If you subtract the BS about "open source and blogs" then his post boils down to his typical advice of try some new things and encouragement to make your own startup but the first half, the basis for that advice, is pretty far off the mark.

So what aren't you going to learn from open source? Well, you are not going to learn that open source is more efficient than closed. If that was the case there should be more open source and it would appear before the closed but mostly open source is copying the closed source and still playing catch up except in 1 or 2 cases.

You are not going to learn that homes are better than offices. Successful open source is not generally not made in homes. You are not going to learn that amateurs do better than pros. Successful open source is mostly made by pros.

Paul claims these are the big lessons. (1) that people work harder on stuff they like, (2) that the standard office environment is very unproductive, and (3) that bottom−up often works better than top−down. 1 and 2 were true long before open source and 3 the key word is "often" not "always", not even "most of the time".

p.s. this is NOT an attack on open source. I think open source is great and I contribute myself. It's only a comment on conclusions I perceive as false.

Comments
ARC vs ZIP, the myth, the legend
Best Game Ever