Whatever happened to support directly from developers?

Monty’s explanation of why he founded the Open Database Alliance focused on the Alliance being able to target customers that need more personalized services than Sun/Oracle could provide.  This jogged my memory about one of the early benefits marketed around purchasing open source support.  Namely, that customers could speak directly with the developers of the product.  In this brave new world, of 3 years ago, customers wouldn’t have to explain their issue to one or two levels of support professionals before reaching the actual developer of the code.  This was even while most questions related to configuration, settings, or other issues that a level 1 or level 2 support professional could handle easily.  But, when it was a tough problem, and/or the customer was down, going directly to the developer definitely had its appeal.

The ability to “speak directly with the developer” could not scale with the growth of an open source software business.  Vendors want their developers writing the next feature for the next release, or out doing professional support, not manning the phones to answer configuration questions.   I remember struggling with this issue  when we were crafting IBM’s Apache Geronimo and WAS Community Edition support offerings back in 2005.

I know some closed and open source companies rotate their developers into the support organization so developers can get customer exposure and better understand how their work and the product is used in the field.  However, this staffing procedure is seldom marketed to customers.

I checked the JBoss and MySQL subscriptions to confirm whether they market the ability to speak directly with the developer. As best as I could tell, they do not.

Customers don’t prefer a support triage system.  But maybe they’re not willing to pay a premium for it?  Or maybe larger open source vendors have acknowledged that this feature does not scale, and hence, aren’t offering it?  Maybe it’s a little from column A and a little from column B?

Follow me on twitter at: SavioRodrigues

 

Comparing the JBoss and MySQL acquisitions

Just saw this story on Slashdot which made me think of this post from Marc Fleury.

The Slashdot story questions what/where is the official MySQL tree:

“…With Monty Widenius having left Sun and forked off MySQL for MariaDB, and Brian Aker running the Drizzle fork inside of Sun, where is the official MySQL tree? …. Smugmug’s Don MacAskhill, who is the keynote at the upcoming MySQL Conference, has commented that he is now using the Percona version of MySQL, and is no longer relying on Sun’s.”

In researching a future post I came across this quote from Sun’s Jonathan Schwartz via Marc Fleury’s blog:

“A: First, the personalities involved. Let’s just say that integrating Marten Mickos into a company might be easier than assimilating a few of the JBoss personalities. Marten is a joy to work with and will make this integration work.”

Thinking about JBoss and MySQL today, I can’t help buy chuckle at the quote.  Both JBoss and MySQL have seen their executives leave the acquiring company.  However, for all the “JBoss personalities” out there, not one of them has forked the JBoss code in an attempt to compete against Red Hat.  Not yet at least (you never know what Roy will do ;-).

I truly wonder why.

Maybe JBoss developers are contractually prevented from doing so or have financial incentives not to fork JBoss?  But if so, why wasn’t the MySQL team put under similar legal restrictions and/or incentive plans?

Maybe Red Hat’s history with open source provided for an easier transition than Sun did?  I don’t buy this considering the initial challenges at Red Hat.  Every acquisition has its road bumps, Sun’s challenges with MySQL are no different.

Maybe there were plenty of open source application server choices (Tomcat, Geronimo, Jetty, GlassFish) out there, so the likelihood of a fork gaining traction is too minimal to bother with the effort?  I’m not convinced by this argument; EnterpriseDB/PostgreSQL, Ingres and JavaDB provide enough choice, as do Cloud databases that seem to pop up weekly.

Maybe, as Schwartz foretold, it all came down to the people and the “personalities”, on both sides of the deal

What do you think?

 

Red Hat facing JBoss Hibernate related patent suit

I’ve previously argued that IP indemnification should be as much a part of the software selling process as companies guaranteeing that babies were not harmed in producing their products.  I was later informed that US law can hold both vendors and users of infringing products liable.

I suspect that folks would be surprised to learn which large software vendors do not offer IP indemnification.  The idea being that these large vendors have deeper pockets than their customers, and hence will be sued directly.  This is often not the case with most open source vendors whose customers often have much deeper pockets than the vendor itself.  Only Red Hat, Novell and Sun would fall into the handful of open source vendors that have the financial resources for an IP-related legal battle.  That’s why I’m interested to see what will come of the recently filed case against Red Hat/JBoss.  The claim also names Dell, HP and Genuitec as defendants because the sell or distribute the infringing products.

Software Tree LLC is claiming that JBoss infringes on its patent for “exchanging data and commands between an object oriented system and a relational system”.  I should stress that Software Tree LLC does not appear to be a patent troll; they sell object-relational mapping software for Java.

Software Tree’s patent relates to capability that is included in the popular JBoss Hibernate product.  According to Sourceforge.net, over 4.6 million downolads of Hibernate (and its various packages) have occurred since November 2001.

I’m certain that more than a handful of very large customers have a copy or two of Hibernate running in their enterprise without support contracts with Red Hat/JBoss.  Will this claim be an impetus for buying a support contract, and hence receiving Red Hat’s indemnification?

[UPDATE: 2009-03-05 9.30a ET] I’m told that Oracle is also a defendant, although this filing is from April 2008.

 

JBoss Enterprise SOA Platform

Two days ago I read Paul’s Infoworld coverage of JBoss Enterprise SOA Platform 4.3.

The Platform includes open source projects such as JBoss ESB, JBoss JBPM and JBoss Rules.  I knew something (good) was up when I saw a link to a “Free 30-Day Evaluation Subscription (unsupported)” on the JBoss Enterprise SOA Platform website.  So I emailed the following to JBoss’ Sacha Labourey:

Is the platform more than just downloading the piece parts (in open source format)? Or is there some pre-integration / performance improvements etc in the soa platform? I hope it’s the latter, since it would drive customers to purchase vs. just using the oss piece parts.  Frequent readers will know that I’m a proponent of selling products, not support.

Sacha replied (with slight edits):

At the core, it could be argued that a platform is just a set of project aggregated together. But that would be a very naive view on the quality engineering and release engineering processes we are going through. We take extensive care to make sure these components are compatible together, that they can leverage the same backend integration (databases, JVM, etc.). Obviously, we go through platform-specific testing which cover more than just one feature (or project) but which cover the full spectrum of features (ESB, Drools integration, jBPM integration, Smooks transformation, etc.) We want to make sure that we will be able to support those bits for the next 5 years at the minimum, while providing backward compatible cumulative patches.

Also, this release of the SOA Platform will be the first one integrating with our JBoss ON management product – that’s also something we don’t do for individual components. Also, remember that the SOA Platform can either run standalone or on top of the EAP (Enterprise Application Platform). For the latter, we also need to make sure that the components we pick up for the SOA Platform do not conflict with the ones from the EAP.

Bottom line: it is the latter :)

This is very cool.  JBoss isn’t selling support.  They’re selling valuable products (whether they would state it as black and white as I do ;-).  Selling valuable products, which can’t be acquired without paying for them, is the best way for OSS vendors to grow revenue with category B users.  Actually, in my view, it’s the best way to grow, period.

 

Source code and vendor lock-in continued

Sacha & Bill (of JBoss/Red Hat) made some great points on my previous post on source code and control.

Sacha wrote:

“Savio,

aren’t you mixing “cost of switching to a different software” with the ability to move to a different support provider? … However, migrating to a different subscription vendor is definitively possible. Just look at CentOS and ORCL with RHEL.”

Great point.  But, moving to a different support provider is not usually a good enough answer.  Customers purchase support around product XYZ not just to get support.  They want to ensure that XYZ continues to be developed and enhanced.  Getting support around a project that isn’t being actively developed is really just a temporary situation.  Most companies will want to migrate the application to an environment that is being actively developed asap.  Additionally, simply providing support isn’t a strong value proposition against a competitor offering support and future development of the product.

As for using Oracle’s Unbreakable Linux as proof of being able to change support vendors, I think the jury is out (at best).  If a vendor with the brand, size and resources of Oracle can’t put a large dent in RHEL usage, what is the likelihood that Savio’s Super Support Center is a viable option for customers of say, JBoss AS?

Next up, Bill makes a very good point about standards:

“Unlike vendors like SpringSource, we have been very good about bringing our core technological innovations to standards bodies like the JCP. Specifically Hibernate (JPA) and Seam (Web Beans). We hope to do the same with the innovations we created within our AS 5 microkernel and OSGi.

So, IMO, the combination of standards and open source, gives customers *a lot* of fluidity and is a nice buffer for vendor lock-in.”

I completely agree that standards help to guard against vendor lock-in.  (I also want to give JBoss kudos for working with standards bodies vs. simply playing the “it’s open source, so don’t worry” card.)  However, very few segments of the software market have an open standard that multiple vendors have congregated around.  Subsequently, we’re back to square one regarding open source as a defense against lock in.

But, as Sacha put it:

“…between Black and White, FOSS is a gray, somewhere in-between. Proprietary software is definitively a strong black with not an ounce of gray :) “

I can’t argue with that.

 

JBoss plays the choice card

News from Sacha (and covered by InfoWorld) that JBoss Application Server 5.0 is close to GA kicked off a debate at TSS.  Some commented that they were “Suspicious of anything that takes three years to develop”, while others questioned if there was anything new in JBoss AS5 that SpringSource and GlassFish (or for that matter Apache Geronimo) hadn’t already delivered.  Others congratulated JBoss on closing in on JEE5 certification and refactoring their runtime to be more flexible.

What caught my attention is the way that Sacha (JBoss CTO) responded to two comments from Douglas Dooley.

When Douglas suggested that JBoss shouldn’t talk about the new microkernel in JBoss AS5 when the real value is in Java EE5 delivered in JBoss AS5, Sacha replied:

“Again, read my blog: we are perfectly aware that many of our customers are using very different APIs to leverage our AS services. Most of them rely on EE, some of them on Spring, etc. And that’s fine. I don’t really mind which “wrapper API” they are using: we are here to support them in their preferred scenarios. What matters is how flexible our underlying foundation is so we are able support these multiple scenarios.”

When Douglas commented that JBoss should ditch their work on other OSes and focus on Linux, Sacha replied:

“No worries, we are doing more than fine. But we are certainly NOT going to ditch support for other OSes: we have a significant portion of our users going in production on Solaris, Windows, etc. and again, that is a matter of choice – we won’t dictate that.”

Why did these responses catch my attention?  Well, it’s not because of the technology decisions that JBoss appears to have made.  The move towards a flexible app server has been going on for years and it’s where the industry is headed.  For example, we’ve been down the flexible foundation path since WebSphere Application Server 6.1 two years ago (with more to come in the next release of WAS due out later this year).  The reason is because Sacha focused on customer choice. Even though we compete, I have a lot of respect for Sacha. He’s way to smart to let dogma get in the way of meeting customer needs. The internal decisions that led to JBoss AS5 and the messaging around the product appear to be a direct result of Sacha (and team) understanding what customers truly seek and where they want to head (i.e. JEE isn’t the answer for every problem).

I’ve long written about how WebSphere has been able to grow significantly faster than the market because of our focus on customer choice.  At times this focus stretches us a little too far as we try to reach the largest set of customers with whatever makes sense for that customer. This decision is not easy on the internal organization, but it really resonates with customers (as our revenue can attest to).

As a proponent of OSS, I’m very happy to see JBoss moving in this direction.  As an IBMer who competes with JBoss AS, I say bring it on ;-)