Ever since JBoss, Inc. announced their $10 million in VC funding, people have been gossiping about what this will mean. Bob Bickel, VP Strategy and Corporate Development, has come out to explain the strategy, and answers questions that are out there.
- What is the business plan?
- Taking money from services customers - is that Open Source?
- Is this the next step to doing an "Enhydra"?
- What does this mean for future contributors to the JBoss open source projects?
- Does JBoss make a profit? Is it cash flow positive? Can it really grow?
- If things are going so well, why do you need outside funding?
- Why did JBoss end up with Matrix and Accel?
- What will JBoss do with the money?
- You talk about JBoss "maturing" by having this VC funding - what does that mean?
- What does this mean to JBoss employees?
Read JBoss, Inc. Venture Funding Strategy
It's definitely an original business model: the employees get paid for contributing. Others don't (not necessarily bad.) I just think it's interesting because I think this is how IBM used to work. I know that the airline reservation software they sold in the sixties used to work like that: it came with the source, and many clients modified it. This code is still in use.
And I think the main source of revenue comes from hosting. The code only runs on mainframes, so hosting is done by IBM, and they charge you by CPU cycle (because of virtualization.) There are people who get paid to optimize programs so they can save a few hundreds of thousands of dollars a year in IBM hosting fees.
Guglielmo: It's definitely an original business model: the employees get paid for contributing.
Sometimes it helps to separate the marketing spin from the reality. The JBoss Group employees get paid because they do work that helps to bring revenue to their employer. That's a relatively typical business model, well proven over the past five thousand years or so. JBoss Group revenue is largely in the consulting, training and support business, aka software services, a model well proven over the past forty years or so. The employees may be encouraged to spend time contributing to open source projects, and if that helps the other parts of the business, then more power to them. Whether this angle is well proven or original or not is open to debate and typical historical revisionism. However, don't try to make it more complicated than it is -- the revenue is still simply software services. Not a horrible business to be in, if you can hire cheap and keep your people busy.
Guglielmo: I just think it's interesting because I think this is how IBM used to work. I know that the airline reservation software they sold in the sixties used to work like that: it came with the source, and many clients modified it. This code is still in use.
There are a few minor differences; for example, JBoss doesn't sell either hardware or software. (I would not be surprised to see that change in the future, at least on the software side.)
Guglielmo: And I think the main source of revenue comes from hosting.
IBM gets you coming and going. Hosting. Services. Backups and spare parts. Software. Maintenance. Upgrades. Blue sky. Manuals. Consulting. Training. On site monitoring. Hardware. Tech support. Cabling. You name it, they can get at least 1000 line items on an invoice somehow related to it. Companies don't grow to 80+ billion dollars a year of revenue by giving stuff away. Hint hint ;-)
: Clustered JCache for Grid Computing!
Very nice explanations. Good luck. :)
I hope JBoss can survive. However, we weren't very impressed by the new support offerings. Basically, more money for less time. I wish some of that money went to a lower price increase for current customers. I understand the need for profit, but we were really stunned and disappointed.
Thanks for your feedback. Actually, we did not change prices. I think you are referring to our Developer Support contract, where basically you buy a set of support hours up front and then use them as you go for any question. This was our first support offering and we still have this and we have not changed the price.
The new offering is called Production Support. It offers a 24X7 coverage with different committed response times depending on your need. This is more for production projects, and JBoss is committing to work on issues until they are fixed in JBoss. We also include a bundle of some Developer Support hours in this for help on non-JBoss issues and "how-to's".
We think we are still providing a ton of value at a cost that is much lower than any of the other app servers in the market. And we are not forcing anyone to buy any of our services - you can still use everything for free if you want. And you will note JBoss employees still give a lot of "pro-bono" work on the forums answering quick questions.
Okay, I consider myself corrected. :)
Bob, I'm curious, why did you remove my comments to your blog entry?
To sum up what they said, for those who missed them, I thought it'd be a good idea to separate between church and state, so to speak, but your new naming strategy (JBoss=server=company) isn't helpful, if you see what I mean.
If your plan works out then I suppose it's only a matter of time before we see companies like Tomcat Inc., Apache Inc., Linux Inc., etc.
One can easily imagine the scenario. Something like this:"We at Tomcat are going to make sure that Tomcat performs as well as it can for Tomcat customers. Tomcat users have always been pleased with the support from Tomcat. We feel that Tomcat is now a very strong brand name, and that Tomcat is the market leader in this space". Confusion galore in other words. Heck, just reading your response on the VC money confused me a number of times for this very reason.
Why didn't you consider this when you decided on the new company name?
JBossians seem to have made a second career of censoring comments on their blogs. And not just outright flamebait but a pretty wide swath (although the occasional borderline comment is allowed through to serve as a vehicle for a JBossian to make a counter-point).
I am curious, though. In a response by Bob on his blog, he says:
"Since this is our only business, we intend to do it well, and we are already significantly below our competitors prices - and they can not really afford to change their business models too much. Garter has a new report out on us. In it they say 'JBoss uses its technical and business innovation in the J2EE app server market to take on the industry giants [...]"
There's a few obvious problems here. First, as I've mentioned in the past, those are product company noises, and JBoss is _not_ a product company. In case they have any doubt, look at the standard market valuation formulas for product companies vs. services companies. Those valuations are based on on-going revenues from the _business_. For a product company, that includes licenses, upgrades, etc - as well as support. JBoss doesn't have licenses or upgrades, just support.
And on support - $8K for e-mail devel support that covers just over one-man week of some support/developers' time. Paid documentation. Presumably the "production" support numbers are significantly higher than $8K.
Compare and contrast this to the BEA or IBM. Both have unbelievably extensive documentation available on-line for free. I can't speak for the IBM side, but historically BEA's on-line free support via the weblogic news groups is excellent. By JBoss' admission, the commercial offerings have features that JBoss doesn't have (and doesn't appear to have any intentions of offering anytime soon).
It sure looks to me like for low-end installations, Websphere or Weblogic is the better value. For a low-end license fee, you're probably paying less than JBoss' production support contract, and from what I've seen getting a wider range of support and _far_ superior documentation.
Yes yes, you can get JBoss for free - but we're talking about JBoss Inc. here - not the free JBoss product. People who don't buy JBoss support are invisible to JBoss Inc. from a revenue perspective.
Truly, for the low-end JBoss Inc. appears to me to have priced themselves right out of the market. Which leaves only mid-level and high-level deployments. There, license fees for the commercial companies _will_ have an impact vs. JBoss Inc.'s offerings. But how much of an impact? Without knowing JBoss Inc's higher-level production support contracts, it's tough to say. Maybe they are a win - but by how much? And how will the docs and support compared to BEA or IBM?
It's interesting. JBoss, the code, has traditionally targetted small companies and small installations. But JBoss Inc's support prices seem to be abandoning the small companies and installations. For the higher end installations, JBoss documentation (even the paid variety) is a joke compared to Websphere or IBM, and as I mentioned they don't have the feature sets of the commercial offerings. But the high-end is where JBoss inc. has priced their support prices.
It's an interesting conundrum - the JBoss code is biased towards smaller projects, but the company that's supporting it is going for the big enterprise dollars (but refusing to develop code to match enterprise needs).
This is rather obliquely on point to Rickard's point - the services company and the code base are being fuzzily promoted as kinda-sorta one and the same, and the end result can only be confusion. Further, as I've stated and expanded upon here, the needs and motivations of JBoss Inc. seem a rather poor match to JBoss, code base. The $10MM investment seems to only magnify those differences.
>Compare and contrast this to the BEA or IBM. Both have unbelievably extensive >documentation available on-line for free. I can't speak for the IBM side, but >historically BEA's on-line free support via the weblogic news groups is >excellent. By JBoss' admission, the commercial offerings have features that >JBoss doesn't have (and doesn't appear to have any intentions of offering >anytime soon).
If you can't speak for the IBM side then don't. You are completely clueless how much "documentation" ibm has. Try to create an Mbean event listener on websphere's datasource for example. There are no docs and it will take you weeks of decompiling their code. Try to do the same thing in jboss - under 1 hour. Documentation available blah blah blah - Simply put, jboss is a better product.
I've found about two orders of magnitude more free docs for Websphere than I ever have for JBoss, paid or free.
Build a system on each appserver and you will see how much websphere's documentation is really worth. Having reams of documentation on how to write scripts for deploying/configuring/etc websphere does not mean much, especially when the same "documentation" required to get the same job done on jboss is 1 page.
Having alot of documentation to make up for a obfuscated system does not mean much to real development. I prefer to look at the total package for an appserver - how long does it take to get a system built with all the documentation - and I include the open source as documentation. Unfortunately, useful documentation on websphere is _completely_ hidden but then again ibm global services consultants are another part of their revenue tactic.
LGPL allows users to have and change the source code. If a JBoss client needs to customize some of the code for their own purpose, how JBoss supports this kind of service.
In the article, you mentioned Jboss encourage people to do so, but I want to know a little bit more from an enterprise user point of view.
This is pretty simple. If a JBoss user isn't distributing the product (Jboss code or code changes), then they don't have to do anything - they can just make the mods. Of course, the definition of what "distribute" means is a bit murky.
If the user is distributing the product, or believes they may be in murky waters where some might conceivably think of it as distributing, then the user only needs to publish the source code. They specifically do not have to give the changes back to JBoss or have them committed in the JBoss CVS tree. They just have to make the source available to the public. They don't even have to inform JBoss that they've done this. A user could in fact fork the entire JBoss code base and make massive changes to it that diverged significantly from the "official" CVS tree - so long as they weren't distributing the product, or they were making the source code freely available. This may seem like an unlikely course, but in fact it's not all that far fetched - sometimes the direction of the open source project diverges from the needs of some end users, and the end users find the cost of maintaining a forked tree is worth it. I wouldn't call this a common occurence, but it _does_ in fact happen.
Tying this back into JBoss Inc. - JBoss Inc. doesn't own the JBoss code base, instead many individuals own copyrights to bits of the code. The only thing they own is control of CVS commits to sourceforge.net/projects/jboss, and the trademark "JBoss(tm)". Anyone in the world today can fork that CVS tree, set up their own, and commit away to their hearts content w/out JBoss Inc. being involved in anyway (or having any say in the matter). This is a point that Marc Fleury repeatedly misses. He trumpets the fact the "the code will always be free, since it's under the GPL", but neglects to mention that there is always the potential for multiple, independent, and incompatible versions of JBoss can be created (but you can't call it JBoss). In fact, I wonder what his support contracts say about code mods to JBoss that's not commited to the official repository.
He trumpets the fact the "the code will always be free, since it's under the GPL", but neglects to mention that there is always the potential for multiple, independent, and incompatible versions of JBoss can be created (but you can't call it JBoss).
I think this is the point, the name can never be used on a competing project and therefore there can never be any cunfusion about what is JBoss. I could be wrong about this, but it seems to me this is the very definition of business around open source, brand. Let's say that there are three derivites of JBoss created, called Tom, Dick and Harry, would you be confused which product was realyl JBoss? What about UNIX, do you get confused that HP-UX, Solaris, and AIX were all really the same thing and you did not know which one to use? Would you try to run Solaris on an RS/6000?