google open sourcing vp8 codec

Interesting but perhaps not surprising news that Google will make the VP8 video codec open source. You can read in more detail by following the link but here’s a quick rundown: Many companies have decided to support H.264 for video streaming, including Google, Apple and Microsoft. Others, like Mozilla (the creator of Firefox), have not, as they are concerned about adopting, as a standard, proprietary technology that may one day require payment of royalties. Instead, they have chosen to support Ogg Theora, an open source codec based on a much earlier version of VP8. Making VP8 open source will remove this divide and will likely encourage the adoption of VP8 as a standard in place of either, as VP8 appears to be technically superior to both H.264 and Ogg Theora (which was developed from a much earlier iteration of VP8) and presumably would be free of potential licensing issues (and fees) associated with proprietary solutions such as H.264.

Perhaps not surprising given Google’s approach in mobile (i.e. the Android open source platform). Though it is worth noting that Google isn’t enchanted with all things open source, as evidenced by the hubbub about it and the Affero GPL a few years ago…

The Virtues and Evils of Open Source – Part II

Found the article that triggered my previous post – was a piece written by Suzanne Dingwall Williams in her blog. The nub:

If you want to sell your own proprietary software, make sure you have a strictly enforced policy against using open source. Here’s why: even if you agree that open source has crossed the chasm in the lifecycle that is technology adoption, your investors have not. Even the inclusion of an inconsequential open source tool can cause headaches, or stop a deal altogether.

Here are the concerns often raised about open source at the due diligence stage:
– there is no meaningful warranty or indemnity for this portion of the product
– how do we know the open source license is enforceable?
– do the terms for this piece of open source contaminate the rest of your product?
– if this was inadvertently incorporated into the product, what else was?

I should emphasize that I don’t necessarily disagree with the concerns she notes. They are concerns. Particularly in the specific instance she notes – i.e. selling proprietary software (as opposed to using an open source business model). That being said whether or not the benefits will outweigh the risks will depend on many things, including the business model of the startup (even if one chooses to go the route of developing proprietary software), the license governing the open source code and of course how its used. I don’t necessarily think that companies (including startups) should just have a flat policy not to use open source. But I’ve already rambled on about this in my previous post.

But then again, I’m not a VC. And Suzie apparently used to be one. It would be interesting to know what VCs generally think. Are you a VC? If so it would be great if you could go to the poll at the bottom of the left column. Nothing super scientific, admittedly, but I’d be interested in seeing what the general sentiment is.

The Virtues and Evils of Open Source

Yes, I know, I’ve been behind lately. A ton of very interesting things to catch up on. But I’d like to put in one quick note about open source code. I recently came across an article, written last year by a lawyer, generally advising development companies not to use open source. I don’t quite recall where it was (if I did I’d link to it) but I do remember it being quite clear in stating that using open source is A Bad Thing and to avoid it altogether – not just to be careful, but rather to treat it as one would radioactive waste.

With respect, I don’t quite agree. I certainly advise my clients to take a great deal of caution in using open source code, particularly the GPL variety, and very particularly if they have a desire to keep some or all of their own secret, proprietary code secret and proprietary. That being said, I do have many, many clients who have used open source code to great advantage in various ways. Some have simply used existing open source code to avoid reinventing the wheel (and saving on costs), while taking care to keep viral elements out of their proprietary code. Others have been more aggressive with the open source model and have intentionally decided to use open source as the basis for their business model and making their very own code, or parts of it, either open source or subject to a dual-licensing model. As the Red Hats, JBosses, Sleepycats, MySQLs etc. etc. of the world have demonstrated, you can go open source and still have a pretty viable business. And, of course, there are the “old world” companies like IBM who have decided to go open source (in some limited ways – e.g. IBM’s DB2 Express-C thing).

Of course, this is not to suggest that anyone through caution to the wind and just start pulling down stuff from Sourceforge and whacking it into your product. Use of open source definitely requires some planning ahead and consideration of what the business model and value proposition of your business will be. Optimally, enlist the help of a lawyer who’s familiar with open source licenses to discuss what you plan to do and the packages you plan to use. Or, if that’s not feasible, try at least to read the applicable licenses yourself and ensure you comply with them, because if you don’t think that anyone will notice, or that no one will actually sue you, you may want to pay a visit to the GPL Violations Site and reconsider, in addition to the questions that will be asked of you when the due diligence starts on your next round of financing or, even worse, your (aborted) exit event. Can badly managed open source usage (and I emphasize badly managed, not simply open source usage) kill a deal? Definitely.

In short – I don’t think open source is necessarily a bad thing. In fact, it can be a pretty good thing, not just in the social good sense and all that, but also as a business. But it need to be used taking into account its terms of use and ensuring that its consistent with the strategy you plan to take.

If perhaps there’s one thing I’d recommend it would be for shops to make absolutely sure they have a disciplined approach in tracking where code comes from and the terms under which its being used and why its being used. That applies not only to open source stuff, but also, for example, your programmers taking neat snippets of code from Dr. Dobbs or something else, or coming across a nice little script somewhere on the Web and saying “Gee, that’s neat, let’s use it in our product”.

Anyway, if I remember where the article was I’ll update this to include a link.