Archive for July, 2006

YAB

Yet Another Blog - this time at work, i.e., at Intel. It’s called Is this bugging you, yet? and focuses on issues around open source, both from a developer as well as from an ecosystem standpoint. Some overlap with this blog (maybe), but likely more focused on the topics that I care about in an Intel context (but certainly not expressing Intel’s thoughts on those topics).

As expected there are some rules involved when blogging at Intel that thankfully don’t apply when blogging under my own domain. Still the goals is to make this interesting, as the title might suggest :-)

Thanks for visiting!
I hope this was helpful - if not, please leave a comment and let me know why! Were you searching for something else? Did I miss an important aspect?

So there’s a 80% chance that Vista will ship on time

(at least according to Bill Gates). Well, that assumes that with “on time” you mean “January of 2007″, which by my counting is already the fourth shipping date suggested for Longhorn, I mean, Vista. Originally this was supposed to ship in early 05, about four years after XP came to the masses. Since then it has lost basically all features that seemed interesting (like the new filesystem or some of the (much hated, by some people) changes to its security model). But still, the shipping date keeps slipping and slipping.

It’s easy to be gleeful and poke fun at them. Especially after watching the hilarious video about the Vista features on Google Video where some unkind sole replaced the video part of a Microsoft presentation about Vista’s exciting new features with a video showing all the things the speaker mentions on the long shipping Mac OS X Tiger. Oops.

But back to the delays - is the open source community doing much better? Obviously there’s this wonderful “release early, release often” paradigm in open source that in many ways prevents dreadful delays from happening. And the vendors (like Red Hat or SuSE - I mean, Novell) are doing a decent job to keep schedule slips in the “a few weeks” range (with OpenSuSE 10.1 one of the rare examples). Yet, I don’t think that’s really comparable. The amount of testing Microsoft needs to do to make sure that the whole ecosystem is ready for the move is just unbelievable. And the closed source development model really puts them at a disadvantage. Beta testers of open source OSs simply can take a look at the code and fix it. No such luck with Vista.

But what is more significant here is that things are measured differently. All the public testing of the components (the kernel, the user space libraries, the tool chain, the applications) happens openly and through a huge community in open source; and the Linux vendors then package the result of this and do mainly integration testing for their release. Microsoft on the other hand develops all components with a comparably small team behind closed doors and then unleashes the “fresh” integration of all these “fresh” components on their beta testers. A very different thing to do - and much harder to get right.

So I feel a bit sorry for them. And I feel that some of the comparisons are unfair. But the underlying conclusion doesn’t really change. The open source model is simply superior in creating innovation and timely products for your customers.

Does open source increase your risk of IP exposure?

Obviously giving people source to your drivers exposes all you IP, while keeping your drivers binary only protects the IP from prying eyes.

So why do I waste time writing about this? Because to me it’s not that easy. And as it turns out, it may not be in the real world, either. Plenty of lawsuits are filed based on binary drivers. It is actually surprisingly easy to de-compile a binary driver and get a very good idea what it’s doing. Mind you, that’s illegal in the US and a bunch of other countries that have signed treaties with the US - but in large parts of the world nothing is stopping you from doing that.

There are a number of open source drivers for popular hardware that were developed exactly that way - this started 10 years ago when Matrox before gave us documentation for their chipsets. And continues today. So how much protection is there really in a binary only driver? Not much. You are making it a little harder for people with ill will. That’s all.

On the other side, creating open source drivers allows you to control which part of the functionality of your hardware you expose to the public. It also allows you to influence the thinking of people playing with your chips. And, oh-by-the-way, it gets people to play with your chips - and maybe even develop innovative software that uses the features of the chip that you document and expose in your open source driver.

This is all very simplified, but so far what we have is

  • Binary drivers
    • make looking at your APIs a little harder
    • do not reliably hide your IP
    • do not protect you from patent infringement lawsuits
    • discourage people from working (and innovating) on top of your chips
  • Open source drivers
    • expose what you want to expose of your IP
    • invite innovation and development on top of your chips
    • help you to create a stable API that developers will be more willing to code to

Seems like an easy choice. But I’ll come back to the topic and drill down a little deeper on some of the fears.

FireStats icon Powered by FireStats