rand($thoughts);

Dana asks whether open source indemnification still matters, since OpenLogic just announced that they would indemnify customers for some 160 OSS products.

When we were coming out with WAS CE, this is something we discussed with customers and partners. The typical answer was, “yeah, we’d like to get indemnification, but I wouldn’t pay extra for it, and hey, if someone wants to sue, I’m sure they’ll go after the deep pockets of IBM instead of me”.

At the time JBoss used to make a big deal about Indemnification being included with their Gold & Platinum levels of support. Customers could get unlimited funds for legal defense and towards code repair or replacement from JBoss. Customers could also be eligible for damages up to 4x the value of their support contract with JBoss. Here is the JBoss support datasheet that I’m using as reference. See pg 3 under Risk Mitigation. Notice that the datasheet is copyrighted in 2005. Also, see this posting by Bob Bickel about JBoss touting indemnification for customers.

Now, if you look at the new datasheet (and a link to the JBoss support datasheet that was live as of Oct. 19, 2006), which was “revised 08.06″, after the Red Hat acquisition, you’ll notice that the Risk Mitigation section of the datasheet is absent. This could mean that:

• (a) Risk mitigation/indemnification is no longer offered
• (b) Indemnification is offered for an additional fee if requested
• (c) Indemnification is offered, but customers don’t consider it to be a make/break feature of the support offering, and so, it’s not listed on the datasheet

My guess is that it’s (a), as a result of (c). Namely, customers aren’t willing to pay extra for it. So, Red Hat/JBoss may have decided not to market it and take on additional legal risk without the additional revenue to make it worthwhile. But maybe customers just assume that the vendor will step in should legal action be taken against the customer? So, in the end it’s a wash, because it would look really bad for Red Hat or any vendor to hang their customers out to dry if legal action against a customer resulted from using a Red Hat/vendor supplied OSS product. But that’s just my guess, and I’m not a lawyer.

In any case, I think the fact that risk mitigation/indemnification is no longer being touted as a feature indicates that it’s no longer a decision making feature of a support offering. So, yeah, Dana, I agree with your take on indemnification!

Barely a week after announcing “The death of yesterday’s Datacenter”, Sun CEO Jonathan Schwartz, shed some light on Sun’s Project Blackbox.

I’ll say right off the bat that Project Blackbox sounds like a very cool idea. Not sure that a large segment of customers would find it valuable, but cool none the less.

In “The death of yesterday’s Datacenter”, Jonathan essentially said that the datacenter was dead as computing was starting to migrate from the datacenter into various other devices, including drill bits and dolls.

I disagreed with his view (do a CTRL-F for savio in the comments), explaining that his examples were just examples of ubiquitous computing starting to flourish. And a ubiquitous computing world has room for computing everywhere, especially in the datacenter.

If Jonathan actually believes the datacenter is dead, then why introduce Project Blackbox?

Infoq has an interesting “what if” interview with Mike Milinkovich from the Eclipse Foundation, about what to expect if Sun were to adopt an Eclipse-style governance model for open source Java.

As background: There is the Java SE standard specification which is governed by the JCP and several implementations of the SE standard. Currently, Sun owns the Reference Implementation (RI) of Java SE, although the Java ecosystem (i.e. IBM, BEA, Oracle, Sun, Apache, etc.) all have alternative implementations.

Geir Magnusson Jr. points out that Sun’s intentions to date around open sourcing Java are really tied to open sourcing their implementation of Java SE, and do not really impact the governance of Java, which is still the JCP’s role.

Mike points out, correctly if you ask me, that open sourcing the Java SE RI without addressing the governance of Java will leave many in the Java community waiting for the other shoe to drop.

TheServerSide.com has a post about recent modifications to the JBoss EULA.

I can totally understand the export-control related change to the EULA.

However, requiring 3rd parties enter into a partner relationship in order to ship un-modified JBoss code without having to remove JBoss/Red Hat trademarks seems hypocritical and like an attempt to force ‘new’ partners to join.

On the bright side, this should help Apache Geronimo and WAS CE to benefit from even more 3rd party vendors seeking a rock solid application server that they can build their business on.  ;-)

WAS CE version 1.1, based on Apache Geronimo version 1.1+, has been available for a few weeks now, but I thought these links would be helpful if you’re getting started with WAS CE:

WAS CE overview can be found here

Download from IBM here

Download from OSTG here

Eclipse update manager site is here

What’s new and docs can be found here

Community discussions can be found here

Enjoy, and feel free to email with questions!

If I understand Dana’s point correctly here, he’s saying that as open source vendors start getting a larger part of the corporate IT budget, less money is spent on commercial vendors, thereby reducing how much those commercial vendors have to spend on R&D for future innovations.

We shouldn’t ignore the fact that some of the most useful technologies these days have come from outside a commercial ISV’s doors (i.e. PHP, MySQL or Spring). So, I don’t think we can make the blanket statement that open source growth equals a reduction of innovation. And I don’t think that is Dana’s point.

I wrote that Red Hat is actually spending 3.1x on SG&A than on R&D, compared to an average of 2.6x across IBM, Oracle and Microsoft. On the surface, this could be a double whammy. First, there is less revenue going to established software vendors to pour into R&D, and second the R&D spending of ‘established’ OSS vendors is lower than the proportional R&D spending of their commercial competitors. One could argue that the net result of these two forces should be a reduction in innovation. (We are making the simplifying assumption that R&D investments result in innovations.)

This is a situation where the IBM WebSphere division has done some interesting things. The WebSphere division first decided to use the Apache HTTP server inside of WebSphere Application Server (WAS) vs. the HTTP daemon that was being developed internally. As a result, the development resources that were previously working on the internal HTTPd were assigned to other parts of the WAS team to work on technologies and innovations that customers saw as having differentiated value. In this situation, OSS actually helped to drive innovation from inside a commercial SW vendor by freeing resources to work on innovative technologies.

The next example was the acquisition of Gluecode Software. Through this acquisition, IBM was able to introduce WAS Community Edition (WAS CE) to address the needs of customers there were seeking a light-weight, easy-to-use, free application server, and thereby make some revenue which could feed R&D efforts. It has also allowed IBM to experiment with the OSS business model.

Having WAS CE as a member of the WAS family allows IBM to compete against both commercial application server vendors (BEA) and open source application server vendors (Red Hat/JBoss) in situations where a customer is contemplating open source. So, instead of risking losing such a deal, IBM Is able to offer the customer WAS CE, and thereby gets support revenue. Sure it’s not the same amount as selling a commercial WAS license, but it’s better than not winning the deal. Also, a WAS CE customer gets introduced to the rest of the WAS and IBM Software family of products, so the customer may end up purchasing one of those in the future (equaling more spending with IBM which can go towards future R&D).
Open source and commercial software will continue to exist in a symbiotic relationship for the foreseeable future. The relationship will require commercial vendors to rethink their approaches to building everything vs. building differentiated value on an OSS foundation. And when commercial software vendors start altering their business models, OSS vendors won’t be able to take a business as usual approach either.

Matt has two statements in his recent posting: “Putting risk back on the vendor, not the customer” that I’m not sure I agree with:

[1] “…if the open source vendor fails to deliver ongoing value, you dump them.”
For this statement to be valid in all cases, there needs to be an alternate vendor that you can move to. As an example, let’s say you start with RHEL, and for whatever reason Red Hat support is not to your liking or cost expectations, what real options do you have?

Some will say, well it’s open source, so you could support yourself. In the case of RHEL, you really couldn’t because of the way RHEL is licensed and updates are made available. But besides, you don’t want to get in the business of providing yourself support for a given OSS product, which is why you went to a vendor to get that support in the first place.

On the other hand if we’re talking about a product like Apache Tomcat, or even Apache Geronimo for that matter, you can go to several vendors for support (i.e. Geronimo support options). This is because there are several interested parties participating in the open source community and the community is not owned/controlled by a single vendor.

[2] “On average, proprietary enterprise vendors spend 5-10x more on sales and marketing than they do on R&D”
I thought that figure was really out there, so I looked at what IBM, Microsoft and Oracle spend. To be complete, I looked at SG&A (i.e. sales, marketing, general and administrative) vs. R&D. I also looked at Red Hat to compare commercial vs. commercial OSS:

For the most recent year/6 months (sorry, I was lazy): [UPDATED on 2006-10-31: to include SG&A as % of Total revenues]

So, the 5-10x that the quote mentions is really an outlier. It could be that salesforce.com has to spend so much on SG&A to get recognized in a crowded market. But larger software vendors spend a much lower proportion on SG&A than 5-10x. And as you’ll notice, Red Hat, the perennial OSS company with published financial results, spends 3.1x more on SG&A than on R&D [UPDATED on 2006-10-31: and a whopping 54% of revenues on SG&A compared to traditional vendors.]

While I won’t argue that an OSS project doesn’t spend much, if aything, on SG&A, an OSS vendor, playing in the commercial software world, is going to spend about the same as its commercial counterparts on SG&A as a multipler over R&D spending.

PS: I know the last tow posts have responded to Matt’s posts, but that’s just because he has interesting things to say!

Matt Assay has an interesting post comparing open source to the parable of sowing seeds. The parable describes how only a small percentage of seed thrown across a field bear fruit, these are the seeds that fall onto ‘good ground’.

Matt correctly ties in ‘good ground’ to the early developers that download FOSS software because they are already interested in the product and have a need for it. These developers act to ‘fertilize’ the market & specific customer (i.e. where they work) demand for the FOSS product.

It would be interesting to study what percentage of early adopter FOSS users would fall into the maven/connector categories that Malcolm Gladwell describes in The Tipping Point. I’d bet it’s a significant amount. This would go a long way to explaining how a few early adopters of a given FOSS project can encourage a market to reconsider their software selection criteria.