Why Open Source - an Interview with Engineers

Is this really a serious question?

Yes.

It's funny, everyone thinks that open sourcing just makes sense. I've been contributing to open source software for nearly a decade (which is nothing, I know). I've never been opposed to open sourcing, and in fact, I don't think I've ever really met anyone who was. But I decided to spend some time to write this article and point out some things that people might not have considered. So this blog is an interview with some of my coworkers who also work on the browser. Some of them should be blogging here eventually, for the time being, most articles will probably be mine. As with most blogs, the opinions expressed herein are not that of my employer. Unlike most blogs, I can't even guarantee that they represent my own views, or those of anyone else.

Why Open Source?

The first reaction was: well, why not? OK, fair enough.

Why Not [Open Source]?

1. It costs money. (It's true, everything costs money. Even writing for blogs costs money.)
2. It costs time. Time anyone spends open sourcing is time they aren't spending writing new features, looking for bugs, improving performance, etc.
3. It requires dealing with lawyers. Don't laugh, this is generally a big part of any open sourcing initiative. While the lawyers are actually very reasonable, it's still a time consuming process and most people don't understand enough about licenses, licensing, packaging and runtime interactions.
4. It exposes ugly code to the world.
5. It exposes engineers to customers. Sometimes it's bad enough that engineers can be reached by upper management. They have more than enough tasks to on their plate and getting additional demands adds stress and frustration.
6. It increases customer expectations. Engineers don't magically get better just because the code is open. They still are limited resources.
7. Lose the ability to make wow announcements.

OK, so I answered my engineers' question. Now so, I asked them again:

Why Open Source?

1. It aligns with upstream, reduces deltas and simplifies integrating changes from upstream.
2. It lets us talk about what we're doing instead of being shrouded in secrecy.
3. It highlights things that need to be improved in the long run so that we can fix them before they become problematic.
4. People can choose to participate in improving our code.
5. Allows people to make tweaks without waiting for us.
6. It makes the community happy (we hope).
7. It allows for faster adoption of new features. In closed processes, it can take somewhere between 18 and 30 months to get new features added. If a product life cycle is a year long and you miss it, it'll easily take the shorter number (18), and if the feature isn't valued highly enough, it can easily miss the first release cycle and have to wait for a second.