« April 2006 | Main | June 2006 »
24 May 2006
More on Open Source Risk Management and Licensing
Updated [27-Feb-2008]: Here's the link back to the original post on open source risk management.
Updated [10-Jun-2006]: Added the presentation deck link from the original Marcusevans conference from Jan 2006 in San Francisco.
Updated [7-Jun-2006]: Helpful suggestions were made and incorporated. The new PDFs are up.
At the end of January, I delivered a presentation (PDF 304.7K) to an open source conference on open source licensing and legal risk management. We still find that some customers hold back initially from formally adopting open source policies because of concerns over licensing complexity or legal risk. (This despite the amount of open source use that may be informally going on behind the scenes in many places.)
I just completed the two white papers that "back" the presentation and published them on the Optaros web site. As with all the Optaros white papers and reports, we have published them under a Creative Commons license in the hopes that the work can be more easily used broadly.
- Open Source Legal Risk Management in the Enterprise, Version 1.2 (PDF 97.4K)
- Understanding Free and Open Source Licenses, Version 2.1 (PDF 95.7K)
Comments and new ideas are welcome as always.
May 24, 2006 at 12:29 AM | Permalink | Comments (0) | TrackBack
16 May 2006
Open Source Software Business Growth Round-up
The discussion has wandered around a few blogs now, and I wanted a place to round it all up. The thread so far:
- We began with Matt Asay raising concerns about the downside of open source business models being freeloaders and leakage.
- I argued back that your community is your strength — that they aren't freeloaders. There are good comments following the post from Matt, myself, Ken Mulcahy (Virtuas), and Russ Danner. (Eric Albert was another Rotor team member who escaped to Apple to have fun again.)
- Matt pulled back over to his blog for his response to a mutual friend's pricing advice, and followed up with commentary on SugarCRM's model from a discussion with John Roberts (SugarCRM CEO).
- Larry Augustin expanded on his pricing advice on his blog, and Matt responded shortly after.
There's a lot of good discussion here. If I've followed it all correctly, I'll bring out the next set of questions and comments for Matt (but obviously anyone is welcome to comment):
- From Matt: "The difficulty for Alfresco has been that we have quickly been pulled into large, Fortune 500 accounts. It's a good problem, but I readily admit that it can be a problem." So it would seem people ARE paying for Alfresco. And these are big deals in Fortune 500 companies — so you CAN drive revenue while you otherwise focus on the community. That's GREAT! Cross the chasm on the bridge of these customers. (I wish I'd had this problem in Softway with Interix.)
- From Matt: "It's hard to set revenue expectations to zero when customers want to pay for it today. Alfresco isn't alone in this. Mule, the leading open source ESB/EAI platform, is being used in big installations today, as is Xen (XenSource). I think it would be hard to tell Peter Levine (XenSource) and the Mule people to turn that cash down." I don't think Larry suggested you don't take the money. He suggested that the expectations be set that there wouldn't be revenue. Huge difference.
- From Matt: "I don't know any VCs that are patient enough to wait the 5-10 years for
a JBoss, Red Hat, or MySQL to develop."
It's always tricky figuring out when to take the money, at what valuation, with what expectation set. (Red Hat started in '95, took the first round in early '98, and went public in the Summer of '99.) So your investors need to not tinker, and allow you to best deliver to your customers and engage with your community, whom you presumably know better than they do.
I don't agree with Matt that there's more than one business model. (There are very few business models in total — open source or otherwise.) But there are a myriad of problems customers want solved, and for every complex problem, there are multiple ways to solve it. And I push WAY out of the box on this. A customer wants to buy a solution. Taking a vendor centric view that the solution is exactly the software in the box, and therefore the value to the customer must directly align with the value the vendor created building the software (plus leverage/margin) limits thinking in this space way too much.
Moore (Geoff not Gordon) demonstrated in Crossing the Chasm that the vendor with the best perceived "whole solution" wins the business, so the core revenue stream and all its complements. Open source software and the communities that develop and use it provide a wealth of opportunities to develop complement value and pull through around such core offerings.
MySQL seems to be solving problems for three different groups of customers in three different ways around the software base that is the relational database engine. How many other ways can Alfresco be applied to what other document management problems, other than a support and maintenance revenue stream from large enterprise? How many other ways can you engage a community (or different communities) to develop and support the Alfresco code base(s) for the solution of those problems?
People will always pay for a solution they value, regardless of form. I still happily pay for software. Just the other day, I paid my US$25 for early access to the latest alpha version of NeoOffice/J so I could run the Mac-based ODF enabled version of OpenOffice instead of the X11-based version. As r0ml pointed out: information doesn't want to be free -- but it does want to be timely, and I'm willing to pay for that timeliness.
I love this picture. A manager at a previous employer put it up to show how creative the mouse was at solving the problem. Some of us were a bit more cynical and pointed out that the mouse was indeed, still in the box.
May 16, 2006 at 12:05 AM | Permalink | Comments (1) | TrackBack
15 May 2006
ODF Acceptance, Microsoft's Big Lie, and a Standards Primer for Berlind
Last week saw some exceptional posting from Andy Updegrove on the "art of the big lie" and messaging battles between vendors supporting the Open Document Format (ODF) standard and Microsoft. Andy does a fine job of calling the question, and brings an analysis to the story as a standards savvy lawyer that few journalists can in the rush to be "newsworthy". David Berlind followed up calling the question on ISO and the value of standards in such a market contest between vendors. Unfortunately, while Berlind's questions are the right ones, he doesn't necessarily have the background in standards to fill in the discussion accurately. Even Gartner's analysts manage to get it wrong, assuming a 70% probability that ISO will refuse Microsoft's Office XML submission. Let's set some ground work for the discussion.
ISO develops standards through its committees and working groups. Member countries form delegations to such groups, through their national standards organizations (BSI, DIN, AFNOR, ANSI, etc.). Each national group forms opinions and delegations through the participation of "experts" within the country. A lot of these experts work for the vendors. So you'll see coverage by large corporations like IBM and Sun by design. (OASIS and ECMA membership to create the specification, and then through various different national bodies to help encourage ISO adoption.)
It's a game of technology diplomacy, and in the end, after the dinners and meetings are over, the job is to expand one's area of economic influence and defend sovereign territory. Microsoft tends to play the game poorly in so far as they don't necessarily invest to the depth that an IBM does in covering the board, nor do they appreciate that a diplomat is ultimately supposed to be invisible. Fortunately (for the rest of us) they treat it too much like a direct market competition so their actions tend to be highly visible. Their current standards strategy would tend to be patent focused since they appear to be rather (patent) lawyer heavy in the standards strategy team that is part of Legal and Corporate Affaires. Again, they don't understand the economic dynamic.
The potential patent problems with Microsoft's proposed standard can't be fought at ISO or ECMA or any other standards development organization for that matter. Standards and patents are orthogonal.
Standards exist in an economic system to encourage multiple implementations. Patents exist in the economic system to protect a single implementation. By definition these tools are focused on different economically conflicting jobs. This is why every standards development organization needs rules about how to deal with patents. It's not that they are encouraging the licensing of inbound property, but rather they need a way to handle the discussion of such intellectual property when they discover it in their midst, or to at least best prevent it from causing them grief from their own members by having the discussion up front. (OASIS does actually have a great IPR policy at this point, because of how it forces the conversation.) There is no economically feasible way to prevent an outside party with a patent from gumming up the works.
Microsoft will hammer away at their covenant not to sue with respect to patents and their Office XML formats, and ambiguity around which patents are covered under what circumstances. So they likely can demonstrate to ISO that with their covenant they are well within ISO's IP policy and that this need not be a concern. (Even the confusion they continue to engender around C#/CLI, patents, and the ECMA specs turned ISO standards, won't be a valuable example because no one could demonstrate that anyone is being hurt or that the confusion is a deliberate strategy.)
Then there's the issue with respect to competing standards. This too is a red herring.
While ISO certainly doesn't like to encourage competing or overlapping standards, they will not necessarily prevent them. They are a standards development organization in place to ensure that the rules of development are transparent and followed. It is not their role (nor do you ever want it to be) to manage the marketplace through determining the economic viability of a standard.
They would be hard pressed to refuse to accept the fast track for the specification Microsoft drives through ECMA based on a scope that says "just like our yet to be delivered product". That's not to say Sun and IBM participation won't seek to slow it down, and that would be a fine thing, but don't count on blocking the entrance of the standard.
A better way to tackle the problem may be to encourage procurement organizations to consider why they procure to standards. Such organizations want the competition encouraged by multiple implementations, and the value in the innovation beyond the standard those implementations embody. This is consistent with the rhetorical line Microsoft started with those same organizations when first realizing open source might threaten their control. They helped establish the discussion that customers really want to procure against standards.
But it first requires multiple implementations.
It is a very small step to encourage those agencies in their procurements to consider the measure of a standard's success to be the number of implementations of a standard against which they're procuring that presently exist versus promises from vendors of possible future implementations. It opens the door for lots of demonstrations of interoperability between products, allowing the customer to make the decision based on other real world factors.
It forces Microsoft to invest heavily in their relationships with the likes of Corel and Apple to try to cajole and arm twist other implementations of the Microsoft XML formats (which they won't be able to settle until they're ready to ship Office 12) or be caught being the only implementation of their own standard.
A standard with only one implementation, regardless of the imprimatur of multiple standards organizations, is still a failure.
May 15, 2006 at 04:11 PM | Permalink | Comments (1) | TrackBack
11 May 2006
The Upside of Open Source (Business): Community
Matt Asay recently opined on his blog about the downside of open source business models being "freeloaders" and "leakage". I would like to respectfully disagree and offer a different opinion.
Matt makes several points I see differently. From his post:
- You wouldn't be happy if too many customers were using your software for free.
- "You have to be prepared to watch would-be customers, big and small, derive immense value from your software without paying you. Value that they'd gladly pay for in a proprietary world. Value that they would have to pay for."
- We need to make open source software more "sales efficient".
- "You must have a hook that convinces would-be customers to buy, and not merely use. Free downloads invite use, but only some proprietary (pardon the word) hook effectively closes sales."
- "For MySQL (which, I believe, derives a massive percentage of its revenues from OEM/embedded sales), this means that it offers a clean way out of the GPL."
- "Systems integrators and others who make their money on professional services - in the proprietary and open worlds - always have an incentive to drive the cost of software to zero to make their services more appealing/less expensive. This is normal and natural. It's not, however, good for the creators of the software."
I like to use MySQL as a good example here. As Marten Mickos (MySQL CEO) pointed out a year ago at LinuxWorld: The early community is willing to trade time to save money. The later community is willing to trade money to save time. MySQL customers are in the latter group.
Corwin's Razor: If they're not willing to put their money where their mouth is, they're not a customer.
Walli's Open Source Corollary: They could still be GREAT users.
MySQL celebrates the difference between their customers and their community. Despite 4 million plus users in the community, the ratio of support and maintenance paying customers is apparently about 1:1000 users. (Let's for a moment put aside the different OEM revenue stream, and focus on the original business.) MySQL understands that fundamentally those users will NEVER be customers, but provide business value differently. (They may even encourage another set out of the community to become customers of a different vehicle called the "MySQL Network" -- and that's different too.)
Let's look at what those "freeloaders" provide:
- Huge beta test community: Are all of them beta testers? Obviously not. But with a user base that large, they probably have a pretty reasonable test bed of real world experience to match any closed source company, AND some percentage of them will likely even offer fixes, some of which might be good, so the value of that beta tester is higher than a binary beta user (e.g. a Microsoft beta tester). Even with the order of magnitude drop between users, bug reporters, bug fixers, and good bug fixes, a base of 4M means the collection of freeloaders provides a lot of collective value.
- A word-of-mouth marketing organization: Seth Godin regularly talks about "making something remarkable" and let your customers tell your story. In this case, it's let your users tell your story. Larry Augustin presented at OSBC a couple of years ago and talked about reducing the cost of sales on the balance sheet in an open source company, and how that still preserves the interesting ratios to Wall Street. It's about not wasting time qualifying a sale down the "funnel" until you close the sale, but allowing a prospect to qualify themselves down the funnel such that sales's job is the minimal amount of time needed to close. I think we would find that MySQL didn't need a pin-stripe suited direct sales force for some time keeping the cost of sales low. This is incredibly efficient when it comes to the margins.
- A platform innovation engine: Here's where Alfresco may be blind to the opportunity in their community. I imagine the MySQL partner community, i.e. the channel rather than the end customer may be more efficient at offering new innovations on the relational database engine. The average end user may not have a lot to offer in query optimizer skills, but then who should *I* be to judge that fact? A Microsoft story: within 24 hours of releasing the first (beta) version of Rotor we received an optimizer fix for the JIT on the Intel chip set. About twenty lines of code that created a 10% increase in JIT performance. Rotor is a complete C#/CLR/Base Class Library implementation in source form at about 1M lines of code including the test suite. Think about all those numbers for a moment. (Of course we couldn't accept the gift from our community, but that's a different story.) Darned freeloaders.
Disclaimer: Optaros is a systems integration partner of Alfresco. We are not a reseller. We aren't interested in SPIFs. We are technology agnostic and we will listen to our customers -- that's our incentive. But if we use Alfresco as a base for a document management solution for our customer, REGARDLESS of whether or not Alfresco is able to sell the customer on the enterprise edition, we're going to make best efforts to provide any changes, enhancements, and bug fixes back to Alfresco.
This is exactly what Optaros did in the ActiveMQ community. We added a fundamental bit of functionality about a year ago, on behalf of a customer. The customer agreed to assign the ownership of the change back to us to take back to the community, and we appropriately assigned the ownership to LogicBlaze Inc., the maintainer of that community. (It turns out that this piece of missing functionality is what caused a large open source savvy financial institution to pass on ActiveMQ, and therefore LogicBlaze, in the previous year.)
The change we made was certainly "mission critical" to our customer in the context of the solution, BUT it wasn't business differentiating to them, and they were happy to get the change back to the core community for the engineering efficiency of support in the future. They weren't being altruistic. They received value from the software. They wanted to continue to see the value in the software. They didn't want to live on a fork and eat the entire cost of maintenance. Customer wins. We win. ActiveMQ project wins. LogicBlaze wins.
But this presumes there is a fundamental message that is set from the very top. You have to be rabidly fanatical about your community and the contribution they make. If you scare them off, denigrate their work, or down play their importance, then you break the relationship and will get what you deserve. Telling your community they're the unsupported experimental fringe in the same breath that you're telling your customers they should value "your" software isn't a good marketing message. Separate the messages. Two audiences require two discussions.
Lastly, let's take a look at the whole "price" and proprietary "hook" issue. First: price. Price is the "equal sign" in the equation between consumers and producers. It is set by the marketplace, not the producer or the consumer alone. The "hook" is the value proposition to the customer. Here's what the hook looks like: 30 seconds into the discussion with a prospect, the customer says, "Wait a minute: This is a replacement for the over-bloated over-priced document management solution I get from Documentum, and it's an order of magnitude cheaper and easier to use?!?!?! I got to get me some of that!"
It has NOTHING to do with Alfresco's perception of the value of their hard work. It has EVERYTHING to do with the customer's perception of the value of the solution. Microsoft makes this mistake constantly. They can see the hard work that goes into the innovation side of the equation and therefore believes the customer should see it that way too.
Red Hat didn't succeed because they were selling "support and maintenance" on "free software" instead of a "license fee". They succeeded because the customer perceived the value proposition of a well-packaged well-supported Linux-on-Intel replacement for their expensive SPARC/Solaris UNIX environment.
Customers care about business models about as much as they care about patents and other legal tools a producer uses in their operational environment. Communities, however, care a lot about open source collaborative environments. Celebrate the differences between these two groups. Love them each for the value brought to the company.
May 11, 2006 at 07:56 PM | Permalink | Comments (5) | TrackBack

