Building A Great Open Source Architecture

For the past 3 years, we have been busy building out JBoss Enterprise Middleware as the Open Source Platform for SOA. During this time, we have been very consistent in our stance that SOA needs to be Simple, Open, and Affordable. We contend that SOA technologies should be available to all, not just the privileged few who can afford the HUGE license costs.

This approach delivers real value to our customers. And since joining Red Hat last June, there are more and more people around the world who want to understand our strategy, product roadmap, etc.

I use a set of 3 graphics to describe our product strategy. These are designed to illustrate how I see the open source market - one graphic for last year, this year, and next year. The color coding on the slides is meant to illustrate the level of pain (threat level) that proprietary vendors are feeling due to open source competitors.

Needless to say, Operating Systems a la Red Hat, Web Servers a la Apache, Developer Tools a la Eclipse, and App Servers a la JBoss are causing high and severe alert levels for the proprietary vendors. Portal, Business Process Management (BPM), and Integration markets have been gaining ground and should generate strong momentum into 2008 and beyond.

I actually use these graphics for two purposes: 1) to explain to people how open source is penetrating software market areas that are relevant to Red Hat / JBoss, and 2) as a radar screen, of sorts, that I personally use to help identify strategic areas of opportunity/expansion.

For example, looking at the pace of BPM, Portal, and Integration, I ask myself: what things can I do to accelerate those areas. This is why you have seen JBoss spend considerable time and effort over the past two years on building out technologies such as JBoss jBPM, JBoss Rules, JBoss Portal, and JBoss ESB.

So, mapping all of this back to the bigger Red Hat Open Source Architecture strategy yields a product map that looks something like this:
This architecture, from left to right, covers the typical lifecycle areas of Develop, Deploy, Secure, and Manage. I believe we have a pretty impressive array of open source technologies in our architecture today, and I point you to the the recent reactions of some of the major sofware vendors in the industry as proof positive that the threat levels I illustrate above are accurate and real.

In my Open Source Strategy: Freeing Great Technology blog, I outlined the different approaches we take towards expanding our base of open source technologies. With this in mind, I encourage you to stay tuned over the course of 2007 and beyond as we continue to rollout new technologies and services focused on driving real customer value. The fact that this will have the net effect of turning up the heat on our proprietary competitors is icing on the cake.

What areas will we expand into next? Well...you'll just have to wait and see, now won't you? ;-)

Then they fight you. Then you win.

Mohandas Gandhi's quote actually goes: "First they ignore you. Then they laugh at you. Then they fight you. Then you win."

This quote has been a rallying cry for many years at Red Hat, and is oh-so-appropriate given the shenanigans going on in the software market these days. Let's focus on two major proprietary software vendors shall we? In order to protect their identities, I will simply refer to them here as....Thing 1 and Thing 2.

Thing 1 says he will just take our technology and make it his own. He reasons that this will help him deliver more value to his customers. Hello!! The BIG COSTS for customers are in the layers on top. I suggest you read my Building A Great Open Source Architecture blog for an illustration of the technology areas I refer to and how open source is poised to deliver more value in those areas.

Now...let's talk about Thing 2. They offer an entry level product that is "based on open source" as an onramp to their complex, proprietary, and expensive stack of products that they are really focused on selling. And in the process....get this...this is the best part...they claim they are actually more open source than we are. Now THAT is great marketing folks! They have a tiny sliver of their stack "based on open source" and that makes them more open source than JBoss. Read my blog on Open Source Community for my thoughts on that topic.

Anyhow, the interesting news is that Thing 2 is spending time building and marketing what I call a bridge to the past. They have built some tools that help people move away from our innovative and fully featured open source platform for SOA to their low-end "children's edition" onramp. The problem is that their onramp only provides a thin sliver of the functionality that people need for their SOA initiatives....so....oh darn....I guess that means people will just need to buy the other complex proprietary stuff in their portfolio...for real license $$'s. This "bridge to the past" will truly be the gift that keeps giving....only their customers are not the ones receiving the gift, if you know what I mean.

So why are Thing 1 and Thing 2 fighting us so vigorously?
Because they are not happy that we are successfully building out a complete open source platform for SOA that not only encompasses the Operating System and Application Server...but also covers the market areas of Portal, BPM, and Integration among others.

They see our big picture. They see our great technology and services. And they will do whatever it takes to preserve the lock-in and huge license fees provided by their big proprietary stacks.

Thing 1 and Thing 2 are more focused on trying to slow us down, rather than on delivering increased value to their customers. And I believe customers and the market in general are smart enough to see that.

What Do You Stand For?

I've spent the better part of my career as a software developer, bouncing back and forth between Product Management/Marketing and Development since 2000, and programming since the mid-80's before that. In my transition to the Marketing "dark side", I have to admit that it took me a while to get what "Brand" really means.

Yeah, yeah, I know...it's simple stupid! Kleenex, Band-Aid, Google, and Coca-Cola are examples of good brands with well established trademarks. It's easy to spot good brands....but....how do you think they got to be valued brands in the first place? How much effort did it take for them to build real Brand Equity that fuels their business?

Red Hat spends a lot of time, money, and effort on establishing our brand. Red Hat has been named the industry leader in delivering customer value 3 years running. In order for our brand to maintain its value, we need to ensure our trademarks are used in a proper and consistent way. If not, then legally we can lose our trademarks. For example, "elevator" used to be a registered trademark but the owners allowed their trademark to be used unchecked as a generic name and ultimately lost their trademark protection. Band-Aid, on the other hand, has protected its trademark over the years and maintained its brand equity.

Red Hat and the proper use of the Hibernate trademark was a topic of debate in the news recently. Since I am not a lawyer, have no desire to be a lawyer, and want to avoid legal debates on this topic, I will simply point folks to the Red Hat Trademark Policies page which contains links to our detailed Trademark Guidelines document and Trademark Style Sheet/Usage document for the official details.

When you look at the details of the Hibernate issue closely, it really comes down to the importance of protecting the brand equity built up in the registered trademark. There are guidelines for how to properly use trademarks, such as Hibernate, and following these guidelines is really not an onerous task. Allowing people to not follow the guidelines is a sure path to losing your trademark and subsequent brand value.

Bottom-line: If you cherish the value of your brand, then every now and then you will need to defend what you stand for.

OFF TOPIC: Is Mode-F Aptly Named?

My kids have been complaining that the special Windows keyboard we have acts weird, forces then to scream at their friends when they are IM'ing, and at times, displays a series of never ending "/" characters or just refuses to display any letters whatsoever.

I'm an electrical engineer by education and have been in the software industry for 20 years, so I've ignored their complaints, assuming they are overstating the situation as kids sometimes do.

Well...as I was sitting at the family computer this morning, sipping my coffee, reading through the land of news and blogs....the keyboard starts getting a mind of its own. With no rhyme or reason, EVERY LETTER I TYPE IS IN ALL CAPS. Toggling caps-lock sorta helps but causes other issues.

I begin to search online forums for some help and I see mention of the "Mode F" button. I toggle the Mode-F button and get a stream of unending "///////////" across my screen. Hitting the Escape key about 1000 times seems to solve the problem, and things go back to normal...for a few minutes.

Then the fun just repeats itself over and over like a frustrating scene from Ground Hog Day.

Well as they say here in Philly....Mode-F me? Well Mode-F you.
I quickly called my uncle Tony...and needless to say there is one less keyboard in the world today. :-)

SCA, OASIS, and the JCP

My take on Mark Little's InfoQ post on the news that SCA/SDO go to OASIS is that the move makes a lot of sense. I'm actually amazed it has taken this long to happen. SCA/SDO are language/platform independent, not unlike a lot of the WS-* specifications on OASIS.

So, much like the JCP has implemented key WS-* specs within the Java platform, they should focus on doing the same with SCA/SDO as the specs work their way through the broader community review/input process.

On a related note, there's been way too much chest-thumping on SCA being a threat to Java EE, JBI, etc. Mike Edwards offers a perfect overview of the Relationship of SCA and JBI; lays out the similarities and differences nicely. SCA is from the tops-down user perspective; JBI is from the bottoms-up platform builder perspective. While they may share some similar patterns, those who pit SCA vs. JBI only demonstrate their inability to distinguish between the two perspectives.

Bottom-line: It is time to get the SCA/SDO specs out in the open and let the community process take it forward.

Open Source Strategy: Freeing Great Technology

At Red Hat, we are 100% focused on an open source business model and what we call the democratization of technology. Let me elaborate on what this means and how it fuels our strategy.

Having been with JBoss since 2004, our approach to expanding our base of open source technologies and accelerating innovation has been accomplished using one of the following approaches:

1. Work within existing open source communities. Our work on a wide variety of Apache projects and Eclipse projects are examples here.
2. Create and staff new JBoss projects. JBoss Seam, JBoss Portal, JBoss Messaging, JBoss Web Services, and JBoss ESB are examples of projects that fit this category.
3. Identify complementary open source projects and recruit them to join our community. Hibernate, JBoss jBPM, and JBoss Rules are examples here.
4. Free great proprietary/closed source technology. Let me use three examples to illustrate this further.

JBoss Transactions is an example of great technology that was previously proprietary. We worked with HP and Arjuna on freeing that technology so we could enhance our middleware technologies and open up technology to the benefit of the larger community.

Our partnership with Exadel is actually a blend of two approaches. We've added their open source technologies to our community as JBoss Ajax4jsf and JBoss RichFaces. And we are working with them on freeing their great Exadel Studio Pro technology at JBoss.org. Those who want to consume the individual Eclipse plug-ins will have that ability. Those interested in getting all of the Exadel, JBoss, and Red Hat Eclipse tools in an integrated and tested offering will be interested in the Red Hat Developer Studio.

Finally, our new Hibernate Shards project was developed by Software Engineers at Google who created some really cool technology built on Hibernate and then decided to free that great technology for the benefit of the broader community. Max Ross at Google describes the process in his Ode to Hibernate blog. Thanks Max, Tomislav, and Maulik and welcome to the community!

As I mentioned in my blog on Open Source Community, while I consider the open source projects and people who work directly on those projects as the core neighborhood within the "community", I do think the definition of community is broader and includes neighborhoods that extend beyond the core neighborhood.

I love working at a company whose core strategy is focused on constantly extending our community so we can free more and more great technology. It is much more difficult for proprietary closed-source sofware companies to follow suit since they are continually lured by the siren’s song of license sales and using “open source” as a marketing tick rather than as their raison d'etre.

Open Source Community and Barack Obama

So you are wondering what Barack Obama and the open source community have to do with eachother? Well I've been catching up on blogland recently and came across a few new posts arguing the definition of open source community and implying the way we do things at JBoss is less pure than it should be. The argument laid out by posts like these actually reminds me of the wave of press focused on the question: Is Obama Black Enough?

"Obama's mother is of white U.S. stock. His father is a black Kenyan," Stanley Crouch recently sniffed in a New York Daily News column entitled "What Obama Isn't: Black Like Me." "Black, in our political and social vocabulary, means those descended from West African slaves," wrote Debra Dickerson on the liberal website Salon. Therefore....Obama is not black enough. Makes logical sense, right? Uhhhh.....I don't think so!

The definition of open source community isn't as singular in nature as some would like you to believe either. Definitions of open source community that focus on one way to do things or one way to interact and communicate are missing the bigger picture. Open source communities extend beyond those who interact directly on the open source projects, mailing lists and forums, and include the users, customers and partners in a wide variety of ways. In my opinion, there are neighborhoods within the larger community that have their own perspectives and ways of interacting with the larger community. So, yes, there is the core open source development neighborhood, but there are also neighborhoods for customers, partners, indirect users, etc. and they are all active community participants in their own ways.

In order to reach out to this bigger community, the Professional Open Source model we use at JBoss enables our developers to spend some of their time delivering services to our customers - via support, training, or consulting. This affords them the ability to interact directly with users who may not be subscribed to the individual project mailing lists, forums, etc. We also have Product Managers, Sales Engineers, Support Engineers, Trainers, and Consultants who spend a lot of time with customers and partners discussing and understanding their technical requirements and funneling that input directly into the open source process. At Red Hat, we spend a lot of time looking for new ways of serving, expanding, and recognizing our community including user conferences, roadshows, Innovation Awards, Red Hat Challenge, client advisory boards, web conferences, face to face meetings, etc.

The definition of open source community need not be so black and white.
Like the software these communities produce, the definition of community needs the chance to evolve and change in ways that we can't even imagine.