it.can presentation on open source

I gave a speech, along with Thomas Prowse (Genband) and Fred Dixon (Blindside Networks) at the IT.Can Annual Conference (PDF) in Montreal last week. The following is the paper that went along with the presentation, for whatever it’s worth. Not particularly earth-shattering but an approach that is a little different than user/purchaser centric approach I usually see about the topic in other papers and presentations, at least within the realm of those addressed to lawyers. Also in Word format: IT.Can 2010 open source (paper) v2.

Many other great presentations as well, by some of the leading IT practitioners in Canada. Not a member? Consider joining. Well worth it.

OPEN SOURCE BUSINESS MODELS

by David Ma[1]

1.                  INTRODUCTION

This paper will: (a) review some of the more common business models used to exploit intellectual property; (b) describe, in brief, what open source is; and (c) identify characteristics of open source licenses as they pertain to those business models.

It is oriented primarily to owners or developers of intellectual property that are contemplating the alternatives available to them in the commercial exploitation of that IP. The general context on which this paper focuses is the development and exploitation of software. However, some or all of the principles described below may be applied in other contexts, and we describe some of these briefly toward the end of the paper.

The intent of this paper is not to advocate open source business models as the definitive way to undertake such a venture. Rather, it is to familiarize the reader with the underpinnings of what is becoming an increasingly prevalent approach to exploiting IP which warrants serious consideration as an alternative to more traditional methods – namely, a proprietary licensing model which emphasizes the treatment of underlying source code as a trade secret. It may well be that the particular circumstances of a business undertaking do not lend themselves to such models. However, it would be, in the author’s opinion, inadvisable not to give them due consideration.

Read more it.can presentation on open source

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…

asp issues

Will keep this short – I was reading an article (whose authors will go unnamed) describing some recent trends in software licensing and issues arising from those trends. One trend that was highlighted was the change from licensing of software to be installed and operated by a licensee (with maintenance and support from the licensor) to a vendor-hosted model (or “application service provider” or “ASP” for short), where the vendor instead sets up the software on its own machine and the vendor’s customers then make use of the software remotely – often through a browser, but sometimes through other “thin” clients.

What was the primary issue they identified? To make sure you get acceptance testing. Hmmm. Well, hate to disagree but I would think there might be a few others that might be at least (if not more) important. So, without further ado, some thoughts on what to keep an eye out for if you are thinking of signing up to an ASP service, in no particular order:

Your Data – Will your ASP be storing your data? Will it be your primary repository of your data? Is your data important? Does your data contain sensitive, confidential or personal information? If so, then you should make sure that your ASP is handling your data appropriately, including giving adequate assurances that it is only used for providing the service (and not anything else) and that appropriate security measures are taken to protect it, such as encrypted communications when sending/receiving as well as encrypted storage. We’ve all read the recent horror stories about certain large corporations who have misplaced, lost, or inadvertently disclosed sensitive data, such as credit card numbers. Make sure it isn’t your company making the headlines.

Service Levels and/or Easy Outs – Addresses the same issue as acceptance testing but in a different way. Typically one big advantage of ASPs is that there is no big upfront licensing fee and therefore no big upfront capital to invest, or risk regarding that capital investment in the event the software doesn’t do what it was expected to do. Thus, the concept of acceptance testing was invented to address this big upfront risk, with the thinking that you get to kick the tires extensively before you hand over the the truckload of cash. And if the testing doesn’t pan out, you don’t pay. OTOH, ASPs usually involve a periodic (typically monthly) payment which is much smaller. In effect, the monthly service fee can be thought of as a replacement for: (1) the amortized cost of the initial license fee; (2) maintenance and support; (3) investment in hardware and infrastructure; and (4) additional people costs on the vendor side, to keep (3) up and running. Very often this is a win-win situation, since vendors can often achieve economies of scale by running a large number of instances centrally at one dedicated data centre (and ironically to some extent harkening back to the days of mainframes + terminals – but I digress) and offer very attactive savings over what it would otherwise cost a customer to maintain the application in-house.

Anyway, the point being that there is less upfront risk with an ASP solution, provided of course, you’re: (a) not locked in to a 50 year contract; or (b) you have really good assurances that the software will be up and running as needed when you need it. Its good to have both, but at the same time it can also be thought of, to some extent, as an either-or proposition – if you can arrange for a month to month contract, then if the ASP stinks, just terminate and go elsewhere. Alternatively, if you get ironclad service levels (including significant credits and termination rights) then you might be willing to commit longer. Of course, you’ll also need to ensure that you have the ability, in the case of a month to month agreement or termination rights, to move to another service easily, and to get your data back, etc. But I’ll leave that for another time.

Anyway, not necessarily saying that acceptance testing isn’t important (and in fact if you need to spend a ton of money to have the vendor customize a solution for you it may still be very important) but just a couple of other issues to keep in mind.

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.

The Exciting World of Licensing Metrics

OK, off the policy/opinion track for a moment, and on to more technical stuff. Most of you will probably consider this topic rather dry, but it is something that lots of folks in the tech industry do think about (and should think about).

Just to quickly summarize, the article speaks briefly to the various types of metrics that can be used to price software, and the complexities that have arisen given things such as multi-CPU computers, multi-core CPUs, virtualization technology and clustering technology. Anyway, the article is a bit of a sales piece as it concludes that the answer to all the complexity is, of course, how the author’s company is doing it:

Subscription pricing models have become increasingly popular in the past few years. Open source software companies typically charge for support on an annual basis, rather than for one-time software licenses. But those contracts are still often based on the number of processors involved, leaving CIOs in the same bind. For our part, we at Sun want to simplify pricing and planning even more: Subscriptions for software are still actually subscriptions for support, as Sun’s software is now free and open-source. But pricing is based on the number of employees a company has. To simplify how to determine what that number is, we base it on what the company reports annually to the Securities and Exchange Commission (SEC).

Nothing super new but worth a bit of a read, particularly if you’re a software developer thinking about pricing models.

My $0.02: This works fine for established, cashflow positive businesses, but of course smaller shops very often look at big upfront initial license payments as a type of financing – moving to a subscription model does of course impact this. Yes, I know, sort of stating the obvious. Then again, that does bring up the interesting question of capitalizing subscription/maintenance payments… But that’s a topic for another day…
The Software Licensing Debate, Round 2 – Weigh In – weighin – CIO