Why Open Source - an Interview with Engineers
Is this really a serious question?
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
Why Open Source?
The first reaction was: well, why not? OK, fair enough.
Why Not [Open Source]?
- It costs money. (It's true, everything costs money. Even writing for
blogs costs money.)
- It costs time. Time anyone spends open sourcing is time they aren't
spending writing new features, looking for bugs, improving performance,
- 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
- It exposes ugly code to the world.
- 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
- It increases customer expectations. Engineers don't magically get
better just because the code is open. They still are limited resources.
- Lose the ability to make wow announcements.
OK, so I answered my engineers' question. Now so, I asked them again:
Why Open Source?
- It aligns with upstream, reduces deltas and simplifies integrating
changes from upstream.
- It lets us talk about what we're doing instead of being shrouded in
- It highlights things that need to be improved in the long run so
that we can fix them before they become problematic.
- People can choose to participate in improving our code.
- Allows people to make tweaks without waiting for us.
- It makes the community happy (we hope).
- 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.