April 2007

Roberto wonders if an Open Source Awareness campaign is needed.

If such a campaign takes hold, I’d suggest that the a solid colour not be used for the ribbon. Maybe use a striped ribbon or a ribbon with different coloured spots/squares/stars/penguins/etc.


Well, because most customers don’t adopt open source or traditional software. They use software (and IT) to solve a business problem or address a business opportunity. Having any conversation that ends with “and that’s why you should only use OSS” is likely going to fall on deaf ears (edge-cases excluded).

Customers are continuing to use OSS and traditional software in conjunction to solve business problem or address a business opportunity. This is something MySQL understands when they position themselves as a Toyota vs. 747s like Oracle, DB2 or SQL Server.

I also think Microsoft’s Bill Hilf provides a good example of OSS & traditional software working together for customer/user value:

“If someone needs proof that open source and commercial models/software/hardware/etc. can be and are compatible, just look at the Web. Not only are they compatible, they have proven to be an amazing powerful combination.”

One size fits all is a great motto for a sock vendor, not a software vendor.

I’ve been playing around with Adobe Flex for a few days. Heard about them open sourcing the Flex SDK later this year. Didn’t think much of it, since it was already free. Then I read this from Dana. Maybe Dana has been wearing OSS goggles for a few too many days, but come on.

If you take a second and think about what Adobe wants to do in the market, this move has NOTHING to do with desperation. It has EVERYTHING to do with aspiration. Adobe wants everyone building browser-based rich internet apps to do so with Flex. It’s that simple.

Today, the Flex SDK is free. Free is a great way to attract developers – don’t charge them to learn your stuff. Good is an obvious necessary condition for attracting developers also. This announcement is nothing more than moving to the next level to attract even more developers.

Part of this is because of the proprietary slur against apps that run inside of the Flash player (Flash, Flex & Apollo apps). The alternative to Flex Rich Internet Applications (RIAs) is to use AJAX, and depending on the AJAX toolkit/framework you select, you’re using something that is OSS or proprietary. Here’s a list of some AJAX/RIA vendors. For the most part, you have a much larger selection of open source goodies if you start with AJAX for your RIAs. And your apps don’t need the Flash player to be installed (at the correct version level or above).

As any middleware vendor will tell you, the SDK isn’t where you make money, and that’s not what Adobe intended either. They are going to do that with the Flex Builder and the Flex Data Services product. (I’d guess some version of Flex Builder goes out the door free/OSS in a year).

Adobe is doing the right thing. Getting developers on board with the free (today) and OSS (in June) Flex SDK. When they start writing enterprise applications that need to connect to back-end data, that’s when Adobe will ask for a PO ;-) Arguably, once developers know and are productive with Flex, convincing their managers to write that PO is going to be a whole lot easier.

So, Dana, I’d very much disagree that this is a desperate move.

PS: I wish it were as I’m really not a fan of Flash (from a usability standpoint), but that’s another story :-)

PPS: Surprised that Duane doesn’t have anything to add on his blog.

Before I get started, Red Hat/JBoss have the right & duty to their investors to grow revenue & profits as they see fit. I am certain that a good deal of thinking went into making this decision, especially to consider the customer impact.

Here’s a table that summarizes the likely announcement from RH/JBoss (where JBoss “retro” represents their business model as of 2007-04-23):

Product Source
Fedora Free Open Free
RHEL Free Closed Paid
JBoss “Retro” Free Open Free or Paid
JBoss “Fedora” Free Open Free
JBoss “RHEL” Free Open Paid

The major change is that non-paying JBoss customers will have to build JBoss from source or use the JBoss “community edition” version (whatever they decide to name it) binary. (See below for why each may not be an optimal choice).

If I had to group OSS customers by their likelihood of paying for support/services, I’d suggest these three (other classifications are likely valid also):

1. Cost Contentious: Unlikely to ever pay
2. Scope Contentious: Pay based on app criticality & perceived need for support
3. Risk Contentious: Likely to always pay (i.e. CYA)

Let’s use these 3 categories to analyze the customer impact of using the Fedora/RHEL model for JBoss.

Cost Contentious:
1A] Build JBoss from source: Not sure how many customers will do this. For example, how many customers build RHEL from source (although it’s a different ball of wax with an OS vs. an app server). Sometimes it’s not as easy as it sounds as builds don’t always complete on the first try. I haven’t built JBoss from source (so please leave a comment if you have), but at the very least, it’s one more hoop to jump through. Maybe there will be a market need for something like CentOS around JBoss products?
1B] Use JBoss “Community edition” (or whatever it is called): May not be appealing for production use, since “backwards compatibility” is not guaranteed and you may (inadvertently) use a feature that doesn’t make it to the next release.
1C] Consider an alternative: Customers will choose based on their needs and their comfort with one open source app server community over another.

Scope Contentious:
2A] If the application isn’t business critical: and the impact of a few minutes/hours/days down time does not justify any spending, then see [1A], [1B] and [1C] from above. (Note: customers can define “business critical” differently).
2B] If the application is business critical: and you’ve been using JBoss without support, this move should help you decide to go get support.

Risk Contentious:
3A] Already paying for support/services: Not a whole lot new for you

This move is definitely intended to drive more revenue to RH/JBoss from customers already using JBoss products without paying for support. There is a risk that some portion of these customers will view the move as a reason to consider alternative products. It appears that RH/JBoss feels that there’s more revenue to be had from [2B] than the risk of losing customers from [1C] and some folks in [2A]. And if these non-paying customers leave, did it really cost RH/JBoss something? (Methinks yes, but from a revenue standpoint, no, at least not now).

Interesting times … and definitely worth looking at alternatives (my biased opinion is that you start with Apache Geronimo or WAS Community Edition).

Okay, I do not speak for IBM in any way (read full disclaimer here). But after reading the following from Matt Asay’s post today, I couldn’t resist.

“IBM uses Apache/BSD to burn boats…everyone else’s. :-) The company builds its software business on proprietary software and its services and hardware businesses on open source software (as well as its proprietary software.) This is classic Martin Fink-type thinking, i.e., open source your complements which also happen to be your competitors’ core competencies. The problem is, they’ll likely do the same. Or, more pertinently, an open source competitor will come along that doesn’t have the same need to keep sacred any proprietary software. How do you compete with someone that can drive all software value to $0.00?”

Let’s dig into Matt’s statement:

MA: “IBM uses Apache/BSD to burn boats…everyone else’s. :-)”
How many open source projects does IBM contribute developers, hardware and/or fund to? Let’s take the example of Apache HTTP Server. Long ago, (the royal) we decided that web serving was a commodity and it didn’t make sense to build our own web server to use inside of WebSphere Application Server. Fancy thing was that BEA and Oracle made the same decision. Does IBM get more than it gives to the Apache HTTP project? Yep, that’s what you’d expect from an open community project. But we have a team that is works on the Apache HTTP project day in and day out. What about Apache Geronimo? Yep, it’s the base for WAS Community Edition and yes we have a sizable number of IBMers who work on Geronimo as their day jobs. What about Linux (let’s throw in a GPL project), again, yes, IBMers work inside the Linux community as their day job. Eclipse, check. OSGi, check. OASIS, check. I could go on….

MA: “The company builds its software business on proprietary software and its services and hardware businesses on open source software (as well as its proprietary software.)”
Umm, so yes, IGS will work with OSS based on client needs. But heck, they’ll work with IBM products, Microsoft product, Oracle products or any software the client seeks. Next, does Linux help drive hardware sales? Sure, but remember we spend resources inside the Linux community, so we’re not taking without giving. While IBM may drive $1B (or whatever it was in 2006) from Linux-based software, hardware and services, it is a small portion of our total $90+ billion in revenue. I’d suggest you want to rephrase the statement to read “(as well as open source software)” in brackets.

MA: “Or, more pertinently, an open source competitor will come along that doesn’t have the same need to keep sacred any proprietary software. How do you compete with someone that can drive all software value to $0.00?”
Umm, we’re competing and winning quite well. Thanks for asking :-)

Anywho, aside from this paragraph on IBM that I take exception with, Matt’s post is well worth the read. He hits the nail on the head when he summarizes with:

“Net net: burning the boats is the right thing to do, but which boats to burn…?”

Indeed…Which boats, when and how does lighting the fire help customers? That customer angle is very important and likely the reason that we’ll see OSS and traditional software (happily) coexisting. (Much more on this in a later post)

Since this will be the third one of these posts, I’ve decided to track the demise ;-) of the traditional software market on a quarterly basis (using IBM’s WebSphere branded revenue as the basis – for no other reason than that’s the part of IBM that I sit in. One day I may look at a broader set of companies, but that day is not today).

IBM announced 1Q07 results last night.

A few points:

  1. IBM Software grew at 9% (or 5% at constant currency: i.e. if currency exchange rates were fixed to equal their 1Q06 rates)
  2. WebSphere branded middleware grew at 14% (or 10% at constant currency)

A few more points from this time last year:

  1. IBM Software had grown at 2% (or 6% at constant currency – note how currency fluctuations can impact a worldwide business)
  2. WebSphere branded middleware grew 26% (or 30% at constant currency)

First, our overall Software business is growing faster now than it was in 2006. Good to see healthy growth of 7%, 14%, 15%, 18% and 20% for Lotus, WebSphere, Rational, Tivoli and Information Management respectively.

Second, we saw very healthy, but slower, growth in the WebSphere branded middleware segment in 1Q07 vs. last year. I stress very healthy because 14% growth is pretty awesome when you’re growing from such a large revenue number, which unfortunately, IBM does not make public. But, if you have access to Gartner or IDC data, you can easily get to a ballpark number of total WebSphere branded revenue.

WebSphere Branded Middleware Quarterly Revenue Growth:

Quarter Y/Y Qtr Growth From:
1Q04 24% Source
2Q04 N/A Source
3Q04 14% Source
4Q04 18% Source
1Q05 11% Source
2Q05 18% Source
3Q05 14% Source
4Q05 4% Source
1Q06 26% Source
2Q06 17% Source
3Q06 30% Source
4Q06 22% Source
1Q07 14% Source

Web Application Server Market:
Some of you may say, “come on Savio, you expect me to believe that in the face of open source competition, the application server business is growing at all? Maybe WebSphere Branded Middleware is growing, but the underlying application servers surely aren’t, right?”

Well, I’m glad you asked. I’m even more glad that IBM is making these figures available. If you go to our 2006 Annual Report and then find your way to page 34 you’ll read:

“Revenue from the WebSphere family of products increased 23.3 percent (22 percent adjusted for currency) and was led by doubledigit growth in WebSphere Application Servers (25.3 percent) and WebSphere Business Integration (22.7 percent) software versus 2005″

Translation: The WebSphere Application Server family revenue growth outpaced the figures that you’ll find in the table above. This is because the table above relates to the 23.3% growth and you’ll notice that the WebSphere Application Server family grew at 25.3%.

So, yes, even in the face of open source competition, the WebSphere Application Server business is growing at 2-3x the market. How? We’re helping our customers address their business needs to achieve success. In some customer situations, we help customers achieve success through the use of WAS Community Edition (WAS CE). In other situation we help customers achieve success through the use of the traditional WebSphere Application Server family.

In the face of open source competition, we got involved in the community, and gave our customers more choice, more flexibility and protected their investments. The results are pretty clear.

“One size fits all” is a great motto for a sock company, not so much for a software company.

Take one Savio, one Hilary, one hike along the Inca Trail, one cheap flight out of Buffalo, one conference and one laptop. Try to combine. Waste a whole evening. Get nowhere.

We had a trip to Peru planned before I realized that OSBC started on the day we get back to Toronto. I’ve been trying to figure out how to get to OSBC (1) on time and (2) with my laptop. So far, the best solution involves UPS, but I’m not sure about customs charges etc.

Since I’m trying to get to OSBC, which is Matt Asay’s baby, and I need someone (other than myself or Hilary) to blame, let’s pick on Matt ;-) So, without further delay:

In reading Matt’s post from April 4th: Spring founder says, “Want money? Follow the IP” Matt wrote:

“But plumb a little deeper, and you come up with the notion (valid, in my experience) that the best support and services in open source come from those who write the code.”

I assume that comment was a dig at Oracle’s Unbreakable Linux. If you head on over to the OSBC website and look in the top right-hand corner, you’re likely to see an advertisement for <drum_roll>Oracle Unbreakable Linux</drum_roll> (if you don’t, hit refresh a few times and you will). I found it funny that OSBC would accept advertising for a product that Matt has rallied against since its inception. But the Ad is probably part of a larger media purchase by Oracle on InfoWorld properties or something of that sort. Sorry Matt, couldn’t resist. ;-)

However, Matt’s comment really begs a more important question. If we believe the statement (and to a degree, I do) what does it mean for the OSS ecosystem and customers?

By saying “If you want services/support for OSS_Project_X, go to the vendor behind OSS_Project_X”, are we making a tacit ruling about vendors or consultants who are not the vendor behind OSS_Project_X? Where does that leave vendors like SpikeSource or OpenLogic? Where does this leave individual developers who learn a framework such as Spring in the hope of delivering services using Spring?

But the even bigger question is the impact on customers. Where is the choice that customers are supposed to get with OSS if we’re advantaging one service/support vendor over others in the ecosystem? Wouldn’t the disadvantaged service/support vendors exit the ecosystem over time, because, at the end of the day, we all need to feed ourselves. Now, what happens if a customer doesn’t agree with actions (pricing related, product related, or quality of support related) taken by the OSS vendor in question, what choice do they really have?

One can argue, “wake up Savio, the source is out there, so the customer could just support themselves, or another vendor could pick up the code and start offering support”. Yeah, that’s a great theory, but I really can’t think of more than a handful of successful forks. Forking another vendor’s code to deliver support doesn’t seem like a great business to be in. And we’ve yet to see how well a 3rd party vendor can support another vendor’s OSS product.

The above scenario changes if there are multiple vendors who “write the code” in an OSS project. This is typically true for Apache projects. But most of the other successful OSS projects are run by a single vendor who is doing a majority of the development work, and who is the leading provider of services/support.

The Myth?:
I’ve come to believe that the “choice, flexibility and control” messages that are prevalent when talking about the benefits of OSS aren’t as strong as one would think/hope. Maybe a larger IT organization with deep skills can take on the support work for an OSS project that they’re using. But the majority of customers who are buying support in 2007 are going to be buying support in 2057. I’ve yet to see a good argument of why they won’t be buying support from the same vendor in 2057 that they’re buying from in 2007. If you don’t believe me, go find an unhappy (but loyal) Oracle database customer.

A software decision is as much about a relationship with a vendor (or community) as it is about technology. And like it or not, a relationship involves a degree of commitment. Does OSS really change the commitment required?

PS: I’m only picking on Matt in a friendly way ;-)

What happens when you read that “GPL Code Found In OpenBSD Wireless Driver” and “Google used rival’s database ‘inadvertently‘” within a few days of each other?

Well, I call up a friend/colleague in legal and pose a hypothetical scenario:

Let’s imagine I had a beef with the OSS business model or with a vendor delivering OSS software. Let’s further assume I had enough development skills to write more than <? echo “hey, come here often?” ?>. Next, let’s assume that I fix a bug in OSS_Project_X or better yet, I get commit access to OSS_Project_X and add a new feature. My contributions get accepted and distributed with the next version of OSS_Project_X. Fast forward six months. It comes to light that the code I submitted was actually not my IP. I’d copied that code from another OSS project with a conflicting license, or worse, from a commercially licensed piece of software (to which I had source code access, i.e. I worked at a software vendor).

The question to my colleague was: Now what?

Colleague in Legal (CiL): Well, first of all, I’d want to know if you’d signed a Contributor License Agreement (CLA) (i.e. like this one from Apache). Essentially, were you legally entitled to contribute the IP.

Savio: Okay, let’s say I did sign a CLA and lied, but oh well. Does it really have a lot of weight?

CiL: Well, from a legal standpoint, that CLA you signed is valid. Or said differently, it’s better to have a CLA in place than not. But anytime we redistribute OSS code inside, or alongside, an IBM product, we do a code scan of every line in the product. We look for copyright headers on files or functions and inside of license files. If we’re not sure the license attached to any portion of the code, we don’t use it.

I’m interested in what a typical OSS vendor, or someone like SpikeSource or OpenLogic does in this area.

From what I can tell, most larger OSS projects have a CLA process in place (i.e. Apache Projects, JBoss Projects, Alfresco, Compiere). But, there wasn’t a whole lot of consistency on sourceforge.net projects around CLAs. Could it be that smaller-scale OSS projects don’t consider CLAs as a priority? Which may be a fair trade-off, until a smaller project gets included in a larger OSS project (but I guess that the larger OSS project would consider CLA ramifications before doing so).

I’d also be interested if a typical OSS vendor does any code scans on contributions? This may actually be a bigger deal for someone like SpikeSource or OpenLogic who is collecting OSS piece-parts from lots (hundreds) of different projects, with different governance models and licenses, and doesn’t really control the code coming into the projects.

The GPL/BSD driver issue & Google’s “mistake” highlighted for me that, as a customer, I’d be more interested in what a vendor is doing to ensure that I’ll never need the indemnity clause, than the clause itself.