In the face of increasing availability of open source appservers, John Reynolds asserts that the sad truth for companies that are betting on support revenues for Java EE app servers is that very little support is necessary. Once an application has been successfully deployed and tuned, there just isn't that much need for "care and feeding". This assertion has large implications for commerical and open source companies that are betting their revenue on support contracts.

John's risk-averse company considered switching to a free open source alternative to their current "very-reliable" but "very expensive" application server, but support contracts were one of the first reasons for opposition. Looking at support contracts, their are two parts to their model: 1) Maintenance (patches, upgrades, etc) 2) Access to support staff

John asserts that maintenance is already free with FOSS appservers, which impacts the viability of a commerical support license model. However, John also studied how his company utilizes access to support staff:

As it turns out, we almost never contact customer support with an app server issue. In the rare cases where we have contacted customer support, the "fix" was either in an already available patch or was found via Google while the issue was still being worked."

John concludes that support-based revenue models are simply not going to be viable for commercial or FOSS appservers, and that revenue models surrounding "on-going support" will need to be re-thought.

However, FOSS and commcercial appservers also have other main sources of revenues that can be thought of as "on-going support". One is idemnification, which is one of the main value propositions for companies like JBoss, LogicBlaze, etc. Another is licenses & support for add-in packages to their main offerings. Commercial vendors realized that the commodization of appservers was coming years ago and diversified with offerings built on top of the appserver such as Portal, Integration, clustering/management, etc. Open source business models are beginning to do similar things on a smaller scale, such as offering pre-packaged and certified releases bundled with additional documentation, easy install/monitoring, etc.

It should be pointed out that there's no single definition of open source....

CodeFutures has developed a business model that accomodates Java developers' desire to get their hands on the source code.

If you pay more, you can have source code. It's still protected by copyright and not for redistribution or resale. But it's open because you can see it and modify it and it's usable source code because written in standard Java.

One interesting point: customers are no longer surprised or excited by the fact that source code is available. That's an interesting effect of the whole OSS industry trend.

Mmmh then looks like LGPL was an unappropriate choice for JBoss after all, at least for the Jboss Group, a dual GPL license would have been more adequate ;-)

But I completely agree with Marc: "I you get free, you want a lot of it. If you give free, you're going to give until you're tired of giving, and that's exactly what happens in the open-source community."

... and that's quite a shame. IMHO it is time to come back to some better business rationales: free speech is important, not free beer. Free-riders and lurkers are not so important for the sucess of an open source project. What is more important is that the key team of professional developers can be paid in order to envision, evolve and maitain the base code in the long run. And that is far more important than being able to get a piece of software for free at an instant T.

Then the second important point is reciprocity. Open source is based on the idea of sharing and collaboration. This is a community job. I do not know why, such a point is even not mentionned by OSI. So if you can enforce a fair win-win deal among all actors (users, developers, contributors, investors, etc...), you can get something more balanced.

That is what we tried to do with our license paradigm (cf: www.collaborativesource.org): most of the advantages of open source but with a better quid pro quo among all actors.

IMHO it is time to come back to some better business rationales: free speech is important, not free beer. Free-riders and lurkers are not so important for the sucess of an open source project.

Stephane, the economics are simple: The market equilibrium set by supply and demand will tend towards higher quantities (e.g. maximum consumption) as the price tends toward zero. In other words, economically speaking, it is only about free beer.

What is more important is that the key team of professional developers can be paid in order to envision, evolve and maitain the base code in the long run.

Again, supply and demand: There is demand for services and support for free products as a natural consequence of their use. That demand allows a company (or an individual) to charge for that service.

Furthermore, there is an arguably low price elasticity of demand in this situation, moreso than in the original "purchase" decision, since by the time the support and maintenance decisions are made by the consumer, there is likely a high switching cost. (The software translation of "high switching cost" is "vendor lock-in".)

However, back to the main point:

IMHO it is time to come back to some better business rationales: free speech is important, not free beer.

I've always taken a different point of view: The rationale for a business eminates from the needs of the customer. That should be true regardless of the business, and regardless (in the case of software) whether the software is licensed as open source or not.

the economics are simple: The market equilibrium set by supply and demand will tend towards higher quantities (e.g. maximum consumption) as the price tends toward zero. In other words, economically speaking, it is only about free beer.

Mmmh I do not agree. the market equilibrium fixes the market value. While your product has a certain market value, you can resell it at a certain price whatever the number of units you are selling.

I have not seen the prices of M$ dropping (it is even the opposite) while Windows or Office should already have been a commodtiy according to your speech. Same is true for my car. No price different for byuing a new car for the last 20 years!

So I agree that a piece of software should become after a certain period of time a commodity (= price tends to zero). However my arguments was: is it possible to innovate with a professional open source business model (and not just simply commoditizing an "old" technology).I've always taken a different point of view: The rationale for a business eminates from the needs of the customer. That should be true regardless of the business, and regardless (in the case of software) whether the software is licensed as open source or not.100% agree with you. Access to the source code is simply one argument for the customers among many others. That's said, all things being equal, I would prefer choosing a program with source code rather than proprietary.

Finally and to come back to the price, if your program fulfills a certain customer need, then it can perfectly be sold and certainly more than gratis. Then natural competition among the various players will do the rest. What I was just saying is that, in the professional open source business model, you just give some bananas and resell some apples twice their standard price to compensate your loss on bananas. So what about someone coming and selling apples at the right price?

the economics are simple: The market equilibrium set by supply and demand will tend towards higher quantities (e.g. maximum consumption) as the price tends toward zero. In other words, economically speaking, it is only about free beer.

Mmmh I do not agree. the market equilibrium fixes the market value. While your product has a certain market value, you can resell it at a certain price whatever the number of units you are selling.

Assuming it is not a Veblen good, the cost of the good and quantity consumed will be inversely proportional.

When the price of a non-Veblen good is fixed at zero, the result is that the consumption is maximized.

(A Veblen good is something that people perceive to be rare, so the more expensive it is, the more people illogically want to buy it. I can't remember the exact explanation, but I assume it applies to worthless things like diamonds, etc. There's also a Gilfin or Geflin (???) good, which is like "porridge" (please sir, may I have some more), which has the same price trend for the very poor that a Veblen good has for the very rich, and for precisely the inverse reason.)

Mmmh then looks like LGPL was an unappropriate choice for JBoss after all, at least for the Jboss Group, a dual GPL license would have been more adequate ;-)

True and not true. It is true because organizations like Apache have done a good job at FUDding FSF licenses. More than 95% of our user base does not distribute software so the fear of GPL virality doesn't effect most companies. As companies become better educated with FSF Licensing, a dual-licensing strategy will not be a great model to increase your revenue because the only way to do it is through an increase in market share and you're only increasing that 5% of customers that will pay for dual-licensing.

My interpretation of Marc's comment is the following:

Only a small percentage of FOSS users will pay for support, <br>so you have to have a ton of users to be profitable.

FYI: we're still figuring out what that exact number is and it should be a great gauge for other open source businesses when we do find out. Until our sales pipeline is exhausted, we won't know.

BUT...even if we stay level at market share, all we have to do is be more creative and provide more value-add our user-base will buy into. For instance, our market research has shown that the capabilities we're building into JBoss Network: patch management, upgrade network, application inventory, are additional automated services that customers will pay for.

Open source is based on the idea of sharing and collaboration.

The idea of open source is based on sharing and collaboration, but the reality> just doesn't match the dream as you get closer to mass adoption.

True and not true. It is true because organizations like Apache have done a good job at FUDding FSF licenses.

I think JBoss Inc has been far more active in spreading FUD about BSD-style licenses :-/

More than 95% of our user base does not distribute software so the fear of GPL virality doesn't effect most companies.

Here's the problem that some companies have with the GPL: Define "distribute" in your sentence above. Then show me how your definition of "distribute" is enforced by the GPL.

Some companies are worried about GPL because of such fuzzy wording and they feel they have to rely on the goodwill of the copyright owners not to interpret "distribute" in a way negative to the company. That's one strike against it (and its a whopper). And the LGPL has the fuzzy-wording problem in spades. And here's a hint on that: an "interpretation" on the FSF web site on what linking means in terms of Java has little legal standing regarding the license itself.

If JBoss means what it says then it should state in the license what "distribution", "linking", etc mean and not rely on the FSF to do it.

Strike two is far simpler: some companies really want to be free to do what they want with the source and just plain not worry about it. They may want to make small or large mods to the source and retain the option to maybe "distribute" it sometime in the future. For those organizations L/GPL just doesn't fly. The GPL is really mostly about benefits to the original authors and copyright holders - " hehe, anyone who touches my code must now release the code!". BSD isn't about benefiting the original authors or copyright holders - they pretty much say "Do what you want with this!". From a user's point of view, the latter is clearly _much_ more attractive.

Strike 3 is pragmatic. The GPL only protects narrow copyrights of literal code. This is so narrow that it's laughably easy for anyone to study GPL code in-depth and recreate it in a new form without violating GPL. As one example, imagine a near-literal translation of JBoss into C#. Would such a tranlation be beholden to your LGPL license or not? If you say "yes" then show me where in the LGPL specifically it says so.

As companies become better educated with FSF Licensing, a dual-licensing strategy will not be a great model to increase your revenue because the only way to do it is through an increase in market share and you're only increasing that 5% of customers that will pay for dual-licensing.

I think this question is larger in context that just J2EE app servers. The new age model against what? The "conventional" commercial software product revenue model?

For non open source products, to buy a license one has to pay a large amounts of money upfront. Because of the inherent nature of software (i.e. the fact that software without bugs is a myth) some problems are bound to occur at a later point in time. The fear of this future uncertainty leads managers into buying a maintenance plan along side the main license. This is ridiculous in my opinion and should be changed. In no other industry do I pay a large sum of money to buy a product and then later, when the product turns out faulty, pay more to have it repaired!!! Don't believe me? Ask any of IBM's or Microsoft's clients how much they hate running around getting issues resolved for the very products they paid huge amount of money for, to start with. They just keep paying and paying and paying...

IMO, the new age model solves this problem. It embraces the very nature of software more naturally, in that, you pay less (or none at all) initially for a product... but pay as you go for support/maintenance/training etc.

Bottomline, I will buy the authors argument, if s/he can prove that commercial products (like the ones from IBM and Microsoft) are _not_ earning a large chunk of their profits from support, training, documentation, consulting and the likes. If they are, then this new age open source revenue model in question will and should work. At least in theory it should.

In fact, IMHO, this new age model has the potential to change the way we think about a software product.

If my car turns out faulty, I can have it repaired under warranty... or better yet, If I bought it from CarSense I can return it within the first 90 days!! Ever heard of factory recalls?!? More generally speaking, If a product (say your laptop) has a manufacturing defect, you shouldn't pay again to have the same damn thing fixed that you paid for to start with.

Actually I think the car analogy is quite good.

If I have a 90-day warranty and don't turn on the car radio for the first 100 days, but on day 101 I turn it on only to find that it doesn't work (and probably never did) then I'm pretty much hosed if I didn't buy the extended warranty.

Factory recalls are when the factory gets pushed into paying exhorbitant amounts of money to fix a very specific thing that they decide is worth fixing, usually because they don't want to be liable for the potential litigation that might result if they did not fix it. The software equivalent might be the Microsoft security updates that we get on a regular basis!

Every product has a warranty period, and we all go through that process of trying out everything that we can think of to make sure it works before the warranty runs out. The problem is that acceptance testing in software is a little bit pricier than trying out the cruise control and testing the radio presets. Way too many software features and dark corners, many of which we may not be able to predict we will end up in until we get further down the development road and the feature suddenly becomes relevant.

Way too many software features and dark corners, many of which we may not be able to predict we will end up in until we get further down the development road and the feature suddenly becomes relevant.

Yes, that's true.

With the FOSS model, once somebody illuminates the dark corner, then everybody will have access to the fix (regardless of support model).

The problem comes if you are the first user to stumble into the dark corner. You’ll have to pay somebody to fix the product (or wait for somebody else to do the same).

Assuming that the fix is committed to the code base, the 2nd through 2 millionth users get a free ride. If they are conservative users of the product (and most corporations that mandate service contracts are very conservative), then they are unlikely to ever be the first to stumble into the dark corners.

It boils down to a situation where there is a broad incentive for companies to keep a specific FOSS product in good repair, but there is no way to keep out “freeloaders”. The actual cost to employ programmers and testers has to be paid (or the product will die), but the cost to each individual user has to be very low (or they will opt to take a free ride).

I see the potential for individuals to make good money, but I don’t see the revenue bonanza that Venture Capitalists generally go for.

The actual cost to employ programmers and testers has to be paid (or the product will die), but the cost to each individual user has to be very low (or they will opt to take a free ride).I see the potential for individuals to make good money, but I don’t see the revenue bonanza that Venture Capitalists generally go for.

I agree, but I think there's more to it.

In order to offset the revenue loss due to no licensing revenue, revenue risk on maintenance due to a customer not feeling it's receiving its money's worth, and revenue risk due to potential competition from other firms large and small; a "professional open source" company needs to offer both superior service and a highly competive costs.

The only way for a firm to be profitable and support development efforts using overhead money, it needs to employ the best of the best people, make them accessible to its customers, and charge a premium for this high level of service.

Ultimately I think profits will be limited to less than those of a large law firm, due to lower rates for software professionals (due to outsourcing body shops) and higher overhead costs (due to allocating a percentage of staff hours to product development). Regardless, the people involved, particularly the partners, will likely make substantial amounts of money. They just won't ever become billionaires.

The limiting factor on growth is the firms ability to attract superior people. Putting incompetents on the front lines to deal with mundane issues simply will not cut it. Putting prima donnas with no customer service skills won't cut it, either.

VCs aren't interested in these small pots, and giving VCs a chunk of the profits would leave too little for the partners and employees.

I won't go so far as to say you won't see any billion dollar open source companies, but you won't see many.

The actual cost to employ programmers and testers has to be paid (or the product will die), but the cost to each individual user has to be very low (or they will opt to take a free ride).I see the potential for individuals to make good money, but I don’t see the revenue bonanza that Venture Capitalists generally go for.

I agree, but I think there's more to it.

Finally, somebody with a clue. John made some good points, but I think he is a little naive and has failed to grasp and factor in open source projects that have mass adoption.

It needs to employ the best of the best people, make them accessible to its customers, and charge a premium for this high level of service.

We do have full time services people, but one interesting thing I always loved about JBoss Inc., is that all of our developers, from the CTO all the way down to our junior level are required to do at least 20% service work (support, consulting, training). Not only do our customers get to work with the real developers, but us developers also get valuable insite into how people use our products. A great synergy. What also happens is that our developers obtain soft skills like becoming comfortable speaking in front of large groups of people and interacting with clients. Also, because our developers do these services, they become expert in areas of the JBoss codebase that they would not normally be exposed to.

As far as employing the best of the best, open source companies are in the unique position as they can see the quality of potential hires. We rarely need to see a resume for a development hire. Also, open source developers have a very unique quality not found in the average employee. They have initiative. Most have no idea how rare an open source developer actually is.

Putting incompetents on the front lines to deal with mundane issues simply will not cut it.

You can't have Gavin King answering support tickets like "My EJB doesn't work, please help." You need support engineers to answer the simple questions and escalate when needed. That being said, I've never met a support engineer that didn't aspire to be a developer. What's great about an open source company, is that we are already organized to incorporate contributions and new contributors from anywhere. A support engineer can become involved with development when they have the initiative and can slowly make the transition to development.

Another thing that this thread has failed to identify is that there are other services besides basic support, consulting, and training. One is certification, i.e. JBoss Certified Professional for individuals or JBoss Solution Certification for products. More importantly, there's also scalable, value-add automated services like automatic patch/upgrade networks, security alerts and security patch networks, as well as others that we'll be rolling out this year.

It's up to us to find creative ways to provide value-add to our user base.

I won't go so far as to say you won't see any billion dollar open source companies, but you won't see many.

I'm hoping that the professional open source model becomes the norm in the software industry. Sure, you'll have smaller margins, but you'll have software companies that are much more receptive to the needs of their user base.

John made some good points, but I think he is a little naive and has failed to grasp and factor in open source projects that have mass adoption.

Just wanted to add one more thing. A customer told me once, "If I only use support once in 3 years, the cost of support more than pays for itself." Support is a lot like car insurance. Sure, you may never have an accident, but if you do, and you don't have insurance, you are really f@%'d.

John made some good points, but I think he is a little naive and has failed to grasp and factor in open source projects that have mass adoption.

I assure you Bill, I am not quite as naive as you think. I am a customer. You are a vendor.

In case you forgot, the customer is always right :-)

The larger context from this customers persopective is that many of the current 24/7 contracts that are sold by vendors are being bought for the wrong reasons. They're being bought for "comfort level" and C.Y.A. reasons. They should be bought based on risk analysis and economic impact.

From what I know of JBoss Inc., your company offers excellent consultancy and training, and you are planning an upcoming JBoss network that sounds really useful (and worth paying for). I think you grasp that the "real" value of support from JBoss is to help people design, deploy, and tune their applications to avoid problems down the road.Another real value of JBoss Inc. is your excellent certification program for Hardware/Software platforms.

JBoss Inc. is trying very hard (and succeeding from what I can tell) to provide real value to its customers.

As for the 24/7 "comfort level" C.Y.A. support... Without that option many companies wouldn't even consider your companies product (Regardless of technical merit). They're demanding it, so you have to offer it. I understand that... naive as I am, I really do "get it" (I've worked in this industry for 25 years).

We both know that FOSS Java EE app servers are remarkably well engineered. When used properly they just plain work. Based on usage, they need tuning and tweaking... but that's the sort of activity that should be scheduled, not something that requires a 24/7 lifeline.

As more "naive" customers like me rise through the ranks of IT organizations the number of companies that pay for C.Y.A. "comfort level" support is going to dwindle. Vendors need to plan for that.

John made some good points, but I think he is a little naive and has failed to grasp and factor in open source projects that have mass adoption.

I assure you Bill, I am not quite as naive as you think. I am a customer. You are a vendor.In case you forgot, the customer is always right :-)

Yes, you, John, are always right for the decisions you make for company and the applications you manage. But you are just 1 example of a company. It is fun to make generalizations like you have, but you need to understand that your view is based on the needs of your one company. Maybe instead of naive, I should have said miopic, would that have been less insulting?. Us at JBoss and others in the business like Interface21 see the larger picture because we have a userbase of tens of thousands of users.

They should be bought based on risk analysis and economic impact.

You've hit it! I'm saying for a many companies, the support is worth it if you crunch the numbers. Yes, we're that cheap. Again, think of support as insurance. Companies are willing and wanting to pay for insurance.

I think you grasp that the "real" value of support from JBoss is to help people design, deploy, and tune their applications to avoid problems down the road.

And this is what I think you're missing. The "real" services of helping people design, deploy, and tune applications is a measurable service. The purchasing decisions for these services are much different the support/insurance play.

From various estimates from our own, to other jouralists and analysts, we currently only tap 3%-5% of our user base for revenue. We have yet to come even close to exhausting our sales pipeline. When that happens, we can get a more accurate picture of what percentage of users want/need support. BTW, this number really excites me. Think about it. We increase this number to %6-10% and we've doubled revenue. 12%-20% and quadrupled. This is without taking into account our growing market share. This is why I call you miopic. You don't have the macro view that we have.

As more "naive" customers like me rise through the ranks of IT organizations the number of companies that pay for C.Y.A. "comfort level" support is going to dwindle. Vendors need to plan for that.--John

As more "miopic" customers like you, (is that better?) rise through the ranks of IT organizations, I hope they realize to not only take into account how many times they use support, but how much money in downtime and engineering time is saved. As well as how much money they would lose if they did have down time and didn't have this insurance.

BTW, I have enjoyed your blog and this thread. It is an interesting conversation, isn't it? Who said business was boring?

I think you missed a large point of what John was trying to get across. "Comfort level" support like he's talking about means corporations shelling out tons of dollars for support "just in case" and never actually using any of it.

An alternative model that's gaining popularity is what John originally referred to: support-by-Google (and also support-by-mailing-list). In most cases support-by-google is far more responsive and accurate than old-style support ever was in the 90's and before that. And I think it's clear that for a number of organizations support-by-google is more than good enough. The only real question is how many organizations that is.

I'd argue that the number is big (yes purposefully vague here :-) ) but more importantly is growing at a rapid pace. Why shell out dollars for so-called 24/7 support when you can get support that's more than good enough absolutely free? How often is a google search not going to turn up the answer to a question? How often will you not get a response to a mailing list question in time?

The real question is "How big of a difference does that support _really_ make? And is worth the $$$$?".

Is John miopic [sic]? Or perhaps are you so busy with your 3% that you don't notice what the other 97% are doing? I would argue that to date JBoss has done a good job of picking up the low-hanging fruit - companies and organizations that buy support from everyone and are even willing to pay crazy dollars to do it. But the number of organizations willing to pay 5 or 6 figures to support a "free" product, particularly a free Java product, are relatively small. As John mentions, Java app servers just kinda tend to stay up. It's not like you're supporting something truly complex like Linux. For an app server how many people _really_ need to talk to a JBoss employee to track down problems? How much better is a JBoss employee compared to google?

Towards the end of your post you say "...but how much money in downtime and engineering time is saved. As well as how much money they would lose if they did have down time and didn't have this insurance".

This is rather misleading. Having 24/7 support is not insurance against downtime. It's not even insurance that you can solve their problems. The only insurance there is that JBoss people will pick up the phone and try really, really hard to answer your questions. But this is not the same as insurance.

You may not see it (myopia?) but many people have crunched the numbers and found that Google-support-and-web support solves far more problems than human support does (at least in the case of popular products).

As for how many, we'll see. As I've said JBoss has picked the low-hanging fruit. Now it's time to see how much more difficult the remaining 97% are to reel in.

Support-by-Google can work very well during development. I'm not really convinced it is a comprehensive production support strategy.

It depends on the complexity of the product in question, the criticality of the application, the fragileness of the product in question at runtime, and the exact guarantees a support contract would give you.

For something like a Java application server, what's going to happen in production? And what, exactly, are the support people going to do if one of these disaster scenarios happens? What are your expectations going in?

All 24/7 support means is that someone will pick up the phone on the other end. As Bill Burke said:

You can't have Gavin King answering support tickets like "My EJB doesn't work, please help." You need support engineers to answer the simple questions and escalate when needed.

So if you have a serious problem you're going to be going through escalation layers and intermediaries. You may very well get referred to FAQ's and knowledge bases and the like before you can convince someone your problem is unique and deserving of higher level attention.

And if you do happen to go all the way up to Gavin, what do you think he's going to say to you? "Oh, you have a million line application and it's getting a weird exception? Let me pop over to your place and take a look at it". No. There may be hours/days/weeks/months of back-and-forth, and in some cases the issue may never be solved. Look around at almost any product and you'll find people yelling about some XYZ bug/feature that the vendor hasn't or won't fix.

Now I admit I'm generalizing quite a bit here, and that support quality varies tremendously, not just from company to company but even person to person within a company. But many people have the mistaken view that buying a support contract from someone is a guarantee that they have (to quote you) "a comprehensive production support strategy". And that's just not true.

But many people have the mistaken view that buying a support contract from someone is a guarantee that they have (to quote you) "a comprehensive production support strategy". And that's just not true.

This quality of support is measurable in renewel rates. We would not have been able to triple in size and quadruple in revenue without a high renewal rate. That's the thing about the open source business model, if the product is great and the support sucks, the customer can ditch the support and keep using the product. I believe our company is organized to sustain high quality service.

Typical Mike Spille, pulls out the text he needs to make his point. I bet if I said "Mike Spille thinks JBoss sucks", you'd say, "Ya see, Bill Burke said "...JBoss sucks".

I would say that you should go back and reread my post. You'd see that my overall point was that our support enginneers do development and that our developers do support.

OK Bill, I've gone back and re-read your post. Yes, you try to indicate that "support engineers do development and that [your] developers do support". But this does not eliminate the fact that you do have front-line support people and that you do have escalation procedures. You do, don't you?

This is rather misleading. Having 24/7 support is not insurance against downtime.

I don't think so. If you've used support at least once, you have something to measure against. Others have already made this assessment and analysis.

Bill, you must be studying rhetoric in your spare time :-)

You have repeatedly used the term "insurance". In fact support is not insurance in any sense of the word. I said "Having 24/7 support is not insurance against downtime". And it's not. I'm sure you'll rant and scream that this is somehow out of context, but you did in fact say

Just wanted to add one more thing. A customer told me once, "If I only use support once in 3 years, the cost of support more than pays for itself." Support is a lot like car insurance. Sure, you may never have an accident, but if you do, and you don't have insurance, you are really f@%'d.

What I'd like to know is exactly how JBoss support is like insurance. If I get insurance, the insurance states "If X, Y, Z, etc happen we will reimburse you on a pre-agreed upon scale".

In what way is JBoss support like this? I'm sure you guarantee that you'll answer e-mail or the phone or whatever within some time frame. But what else do you guarantee? Do you guarantee that you will solve the customers problem? Do you guarantee you'll fix it within a pre-defined time frame? Do you guarantee that if the problem is due to a bug in JBoss code that JBoss will fix it?

What, precisely, does JBoss guarantee as part of their support contract beyond the fact that they'll pick up the phone or answer the e-mail?

This quality of support is measurable in renewel rates. We would not have been able to triple in size and quadruple in revenue without a high renewal rate. That's the thing about the open source business model, if the product is great and the support sucks, the customer can ditch the support and keep using the product. I believe our company is organized to sustain high quality service.

You've given us a nice concatenation of assumptions. If we assume that JBoss has quadrupled in revenue (based just on your word) and we assume that much/most of that quadrupling is based on renewals and not other business or new contracts (again based on your word), and we additionally assume that a renewal indicates high quality (we'll just all arbitrary make this leap) then we can assume that the support is "high quality". And we can do all this without a definition of what "high quality" actually means!

Let's put this in more concrete terms. I'm getting some exception I don't understand out of the container in a deployed application. Personally I would google that exception and possibly search a couple of forums to find out what it meant. I might even post a couple of e-mails.

If I have a JBoss support contract, what exactly do I do, and how fast is typical resolution? On the google side I'd say that google gives me a definitive answer in <10 minutes about a quarter of the time. Another 50% are usually resolved in under an hour of poking around. The remaining 25% might involve much more involved poking around, asking people, trying experiments, etc. Actual numbers might vary from person to person and organization but I think these are highly conservative - find the solution in <10 minutes 25% of the time, find it in under an hour 50% of the time, indeterminate the remaining 25% of the time. If you don't like these numbers or feel they're some kind of strawman, fine - pick your own. We've _all_ googled problems and posted stuff to forums. How often does this work for you? How fast does it work?

Whatever numbers you pick - how does JBoss support match up to this?

I have my own private ideas on what the reality is, but I'd love to hear your response. But in the meanwhile - I wonder what the real breakdown is between support contracts, training, and consulting. A little over a year ago you told me, right here on TSS, that JBoss doesn't do consulting, never did and never will. Now you say this:

We do have full time services people, but one interesting thing I always loved about JBoss Inc., is that all of our developers, from the CTO all the way down to our junior level are required to do at least 20% service work (support, consulting, training).

In 2004 you were livid that anyone would say a dirty word like "consulting" to you. Today you mention consulting before training.

What are the real break downs here? How much JBoss revenue really is derived from support contracts vs. training vs. consulting vs. "other income"?

OK Bill, I've gone back and re-read your post. Yes, you try to indicate that "support engineers do development and that [your] developers do support". But this does not eliminate the fact that you do have front-line support people and that you do have escalation procedures. You do, don't you?

He's got you there, Bill. You need an escalation procedure to prevent your best people from being bogged down with mundane questions, but the lag time and frustration that can be created by having to go through escalation is terrible customer service. I suppose the only answer you can give is that your front line support people are better than those of other companies, and they have more ready access to developers and other resources.

You have repeatedly used the term "insurance". In fact support is not insurance in any sense of the word. I said "Having 24/7 support is not insurance against downtime". And it's not. I'm sure you'll rant and scream that this is somehow out of context, but you did in fact say

Support can:1) Provide internal support staff with information that prevents outages due to mistakes2) Assist in diagnosing problems and thereby reducing downtime once it occurs3) If the issue is with the core software, escalate it to the developers and get a patch issued

So good support can reduce the risk of downtime occuring and reduce the impact of downtime once it occurs.

If I have a JBoss support contract, what exactly do I do, and how fast is typical resolution? On the google side I'd say that google gives me a definitive answer in <10 minutes about a quarter of the time. Another 50% are usually resolved in under an hour of poking around. The remaining 25% might involve much more involved poking around, asking people, trying experiments, etc. Actual numbers might vary from person to person and organization but I think these are highly conservative - find the solution in <10 minutes 25% of the time, find it in under an hour 50% of the time, indeterminate the remaining 25% of the time. If you don't like these numbers or feel they're some kind of strawman, fine - pick your own. We've _all_ googled problems and posted stuff to forums. How often does this work for you? How fast does it work?

Leveraging "Google Support" requires a far amount of knowledge on the part of the person seeking an answer. Not only does he have to know what to look for, he has to realize when what he finds is crap. There plenty of garbage out there, even garbage that appears to come from reputable sources.

If the vendor support is good, then you don't have to worry (as much) about your internal staff duplicating some mistake somebody else made and posted that happens to transform an obvious problem into an intermittent one.

Then there's the 1 out of 10 times when you really, truly need expert advice and you need it immediately. You can spend days searching and experimenting without support, or you can spend minutes or hours working with a support person...once again assuming the support person is competent.

My big hangup is I have yet to find a support person who is both useful and readily available.

I suppose the only answer you can give is that your front line support people are better than those of other companies, and they have more ready access to developers and other resources.

Just because you have escalation procedures, doesn't mean you cannot provide high quality of support. In fact, you need strong, efficient escalation procedures in order to provide high quality service. No one person knows everything. Erik, we *must* be high quality or we will not get the renewals that are crucial to building our business. I am convinced that JBoss is organized to provide this high level of support(see older posts).

We try to educate our customers to ask the right questions so that they can avoid some escalation procedures.

So good support can reduce the risk of downtime occuring and reduce the impact of downtime once it occurs.

This is an obvious sales pitch, but our advanced training teaches a lot of internal architecture of JBoss so that we can give our students the tools to navigate through the JBoss source. Another way to reduce your risk.

The thing is, a savvy engineer on the customer side does wonders for us when trying to provide high quality support as it is easier for us to get at the root of the problem. Anything we can do to educate a customer is in our best interest.

Leveraging "Google Support" requires a far amount of knowledge on the part of the person seeking an answer.

We actually encourage people to search on the web. We actually put a lot of effort into expanding this WIKI and also encourage Forum posters to create WIKI pages when they figure out a complex problem.

If a support customer has done at least a little a little research, we can get to the root of the problem quicker.

You can spend days searching and experimenting without support, or you can spend minutes or hours working with a support person

ADP, who was on our customer panel at JBossWorld, is one of those customers that has a staff of engineers, like Nicholas Whitehead, that actually dive into the JBoss code base. They are very knowledgable about JBoss internals, yet still find a lot of value in JBoss support. The thing is, customers want support.

I think that support-only models are rare and rather unrealistic. Most of businesses shipping OS software products will rely on a obvious mix of revenue sources: passive support, professional services/consulting, possibly formal training, and additional components/editions that are not free.

If you take any OS company I guess you would find that it uses some if not all of these sources (with specific emphasis varying based on the product and the type of the market it is in).

Sounds like John is applying the example of how his company is treating their FOSS maintenance to the entire marketplace.

If the people maintaining the app server in John's company know what to look for on Google to find a fix and then apply the fix to the app server, they are probably not your run of the mill high school graduates who administer app servers in hundreds of other companies. I'd venture a guess that they are paid accordingly as well.

The entire premise of buying a support contact is to save money by not having to do the actual work in-house. Instead of paying for a high-talent software engineer who can probably come up with a pretty much any fix for an arbitrary Java app server by decompiling a few class files and spinning some code, a company buying a support contract can get by employing a low cost employee to mindlessly execute upgrade instructions from the app server vendor.

If the people maintaining the app server in John's company know what to look for on Google to find a fix and then apply the fix to the app server, they are probably not your run of the mill high school graduates who administer app servers in hundreds of other companies. I'd venture a guess that they are paid accordingly as well.

You are correct. We have a great support staff.

I'm not personally aware of any companies who hire "run of the mill" folks to administer their app servers... but I would question the ability of a support person who could not research a problem using Google. If they can't express the problem well enough to search forums using Google, then I doubt they could properly convey the problem to a remote support person. Applying the fix might be more problematic... but if the fix is in an existing service pack I don't see how a remote support person is going to provide much value.

Personally, I would spend more on my staff and less on support contracts.

let me assure you, there are plenty of companies like that. they do precisely the opposite of what you suggest - they invest in support contracts and treat internal people as easily replaceable commodity. as a result support folks take every problem to the app vendor, without trying to research it themselves.

Daniel Brum, enterprise application architect at insurance firm Aviva Canada in Toronto. "Your tools and APIs are all open source, but at the same time you provide a corporate backing so we as end users get that comfort level that comes with 24/7 support and the knowledge that all the proper testing is going into these things and that the developers are actually paid to work on the tools."

I agree with Daniel's assertion of what users want... But does this really work in a FOSS model?

the knowledge that all the proper testing is going into these things and that the developers are actually paid to work on the tools.

Hmmm... if the application is FOSS, I get the benefits of this whether or not I pay for support.

I have no doubt that JBoss (for example) produces quality code and tests the heck out of it... but I don't have to buy a 24/7 support contract to get access to their great product.

As for the comfort level provided by 24/7 support... I go back to my assertion that Java EE app servers have a lot in common with the Energizer Bunny. They just keep going, and going, and going....

First off, there is definitely a market for appserver support. Two of my clients, large energy companies, are mandated under auditing requirements to own commercial support contracts on any core piece of software infrastructure. Yes, that includes open source application servers.

It doesn't matter whether developers are supporting the system using Google or phone calls with the support staff; they are still required to purchase the contracts.

Now, what is John's point? Perhaps he is saying that a company like BEA can not maintain a $3.5 Billion market cap if they switch to an open source support model. If so, he is absolutely right. BEA's only hope for maintaining that cash cow is to strike it rich with closed-source higher-level application suites like ESBs. I'm afraid the odds are against them.

But can a company operate profitably providing support on open source software? Of course they can. Maybe only 2% of users end up buying support contracts. But that's OK, because with an open source product is far cheaper to build up a large user base. You will get a smaller slice of the pie, but it's cheaper to bake a really big pie. OK, I suck at analogies.

JBoss Group has done well in support revenue, and I strongly suspect that the folks at Interface21 are able to scrounge up enough for dinner each night.

Will Winston Damarillo rue the day he threw seven figures into Mergere? Sure he will. But companies based around supporting popular, successful, open source infrastructure will do just fine.

Two of my clients, large energy companies, are mandated under auditing requirements to own commercial support contracts on any core piece of software infrastructure. Yes, that includes open source application servers.

It's very common. Open source and commercial companies alike find that they can charge obscene amounts of money for "support and maintenance", and the older and less used a product is, the more they seem to charge.

Companies that mandate support contracts should do TCO studies and negotiate master agreements before even allowing a piece of software to be used. I wish I were allowed to tell in detail some of the examples I've seen of companies getting totally screwed by vendors (both commercial and open source).

In one name-witheld-to-protect-the-parties case, a commercial vendor gave a customer licenses for free, but the support bills (including the one due on day one) were based on list pricing, and the list price was in the neighborhood of $100k/CPU. In other words, if you "give" a customer 50 CPUs worth of software, you end up with a recurring $1 million revenue stream from that customer.

Another customer didn't realize that one of their developers used a couple of open source projects in a piece of software, and ended up having to pay $50k a year for what the developer believed to be "free" open source. (You'll notice that various open source companies don't publish their support prices. It's like they say about restaurant menus: If they don't show the prices, then you probably can't afford it.)

It's unfortunate that there are more people trying to "get rich quick" and less trying to create "the next big thing".

It's unfortunate that there are more people trying to "get rich quick" and less trying to create "the next big thing".

No doubt. The services-only business is immature in the software field, and I have had the misfortune of dealing with some companies while they are still trying to figure out what their pricing models and goals are.

In general, I think that a firm that is willing to sell support on a pure hourly basis, or sells reasonable packages of pre-paid hourly blocks, is very confident in the quality of their offerings, and feels that they can provide good value to the end user that will keep them coming back.

When companies start coming up with abitrary support pricing based on poorly defined concepts like 'Named Applications', it raises a red flag to me that they may simple be looking around to see how much money is in my pocket.

If you grab SEC filings from mature software companies and do the math on sales/marketing, research/development, licensing, support revenues, and services, you can figure out whether a given combination of ingredients represents a plausible stable business model. For example, if you don't need a salesforce but charge normally for support, you can do without licensing.

The question of support for FOSS is one of what makes it onto the main codeline and when, what features are and will be supported, and both timely and direct access to people who truly know the software. (John's dead on that Google is typically a just-as-good or even better knowledgebase than the one sitting in front of a support rep.)

The issue is not how you divide your revenues in how many service or product lines but how much it costs to your company at the end to develop, maintain, upgrade, support, promote and administer (accounting, lawyer,...) a piece of software + perhaps, if you get lucky, some kind of benefits for the shareholders.

So what is the TCO of JBOSS for JBOSS Inc? Of course they will need to pay full time developers to enhance the kernel (and who will not answer to the phone or take the plan to give a training session during this time). I do not include all the business dev team cost, the marketing exepenses, the General and Administrative budget,.... So if you decide to not get any license revenues on your technology(license or yearly upgrade contract), you will have to increase both your professional services or your support fees. That is just some basic math.

But the problem with this kind of business model is that you may face a deeper competition and you put yourself in a difficult situation regarding your partners (=system integrators). Anyone may begin offering support or professional services on top of your product at any time but without having to deal with all the indirect operating costs. moreover in order to compensate your lack of license revenues, you will try to cross-sell more services (consulting, training, architecture, ...) at an higher price per hour. But this is exactly what the system integrators all around the world are proposing to their customers. So you directly compete with them and often at an higher price per hour (they do not have all your indirect R&D costs!). Finally they will prefer proposing to their customer a solution where the roles are clear: the editor make some money on license and support/mainteance, they take the rest.

But at the end we always come to the same conclusion: what's important is the free speech and not the free beer! The TCO will approximately be the same.

<quote>But the problem with this kind of business model is that you may face a deeper competition and you put yourself in a difficult situation regarding your partners (=system integrators). Anyone may begin offering support or professional services on top of your product at any time but without having to deal with all the indirect operating costs. moreover in order to compensate your lack of license revenues, you will try to cross-sell more services (consulting, training, architecture, ...) at an higher price per hour. But this is exactly what the system integrators all around the world are proposing to their customers. So you directly compete with them and often at an higher price per hour (they do not have all your indirect R&D costs!). Finally they will prefer proposing to their customer a solution where the roles are clear: the editor make some money on license and support/mainteance, they take the rest.</quote>

From above statement, it sounds like that it does not make sense to adopt the professional open source business model, as it will lose money and give the business to system integrators. I am assuming JBOSS, mySQL etc. are making profits. Do you have an alternative solution ? Or do you think the professional business model does not work at all ?

I can see the issues you raised, but I hope someone can provides some insight as how to make a profit for a open source company.

From above statement, it sounds like that it does not make sense to adopt the professional open source business model, as it will lose money and give the business to system integrators. I am assuming JBOSS, mySQL etc. are making profits. Do you have an alternative solution ? Or do you think the professional business model does not work at all ? I can see the issues you raised, but I hope someone can provides some insight as how to make a profit for a open source company.

The problem is a bit more complex. MySQL has a double hat with its dual-licensing business model. So in practice, yes, they have license and maintenance revenue streams. From a pure open source perspective, I do not really like the dual licensing approach (for several reasons from the GPL viral effect to the fact that you freeze access to the CVS to third party committers in order to keep 100% of the IP rights in order to be able to dual license the program).

Professional Open Source is also easily possible if you are large enough (= big players) and able to put in place some cross-selling opportunities within your company (I give you this but in exchange I will be able to sell you that (hardware), that (proprietary modules) and that (consulting services)).

Now the question is more: is it possible to start a small open source company from scratch without a lot of cross-selling opportunities and focused on one single product, to invest quite a lot of VC (or your) money in the R&D and keep a competitive advantage in the long run versus other integrators/editors who may decide to join the train meanwhile and perhaps assign more ressources on the project that your are able to assign to? Are there a lot of open source start-up funded from scratch with a Professional open source approach (ok alfresco.com recently ;-))?

IMHO, even if your product is successful (and it is the first risk for the VC), you also risk that, once the product is developed, one larger company with offices all around the world decide to offer support and services on top of your platform without your prior consent and your original R&D investment costs. So what would be the return for your shareholders?

Note that I am not against OSS projects. This is even the opposite as my company contributes in several of them and we also open source several of our libraries. I am simply not convinced of putting in place a viable business model on top of a new 100% OSI compliant project (excepted the dual licensing approach exception). I must also say that I am located in Europe and that we do not have here a gift/donation culture like you have in the States. I have not seen a lot of French companies freely give 10K to a project just because it was nice and they successfully used it during the year. So if you do not force them a bit, they will just try to act as free-riders as long as they can.

But as mentionned, IT managers begins to understand that open source does not always equals free (like in beer) and begin to understand that, either directly or indirectly, they will have to pay for something. So the important point is again the TCO of the overall solution on 3 or 5 years + the risk taken if the lead company on the project goes bankrupt vs full access to the source code for easier integration and/or bug fixing.

Not surprisingly, at JBoss, we have run into the scenario you described below:

"IMHO, even if your product is successful (and it is the first risk for the VC), you also risk that, once the product is developed, one larger company with offices all around the world decide to offer support and services on top of your platform without your prior consent and your original R&D investment costs. So what would be the return for your shareholders?"

This occurred with a several million euro RFP for the DGI (Direction Generale d'Impots) Copernic overhaul of all tax IT system applications for the French government. JBoss partnered with Atos Origin on this deal and Cap Gemini chose to use JBoss as their chosen app-server in this bid, without partnering with JBoss, Inc. They clearly told us "why should we pay you anything when we can develop our own JBoss competency center in house?" This RFP included five days of comprehensive testing on the RFP participants' ability to support their chosen software platform for a hypothetical application. The JBoss Atos Origin scores completely blew the Cap Gemini on JBoss scores out of the water.

So yes, the answer is that any large SI is free to support FOSS software without any kind of partnership with the commercial entity or developers behind that software. However, the investment in developing in-house competency on a complex piece of FOSS software will usually always be far less than the cost of a partnership with the commercial or developer entity that writes this software. And the level of support delivered by a non-partner SI on the given piece of FOSS softare will usually be of far less quality than that of an entity whose business is purely focused on the FOSS software in question.

JBoss and Atos Origin won that deal and several months later Cap Gemini signed a partnership with JBoss in Europe.

On what basis was the bid actually won? You mention something about how well you scored on one tiny piece of it but do not say the factors that materially impacted the winner of project. Did your bid win solely because of your stellar ability to support JBoss, and Atos Origin just kinda came along for the ride?

Was cost perhaps a factor in the various bids? Did Cap Gemini lose because of their ridiculously low score on supporting a "hypothetical application" or did money come into play anywhere?

How much of the "several million euro"s actually go to JBoss and how many go to Atos Origin? Considering that you certainly got only a fraction of the total and not the whole thing, was the cost of sales worth what you finally got?

Finally - for each one you've won how many have you lost? And how much of this activity is organic and self-sustaining and how much due to ephemeral VC activity?

I'm not saying that either viewpoint is right here, but instead I'm pointing out that your post very carefully did not say several key things :-)

Fascinating wording employed in this post, Nathalie, utterly fascinating.On what basis was the bid actually won?... You mention something about how well you scored on one tiny piece of it but do not say the factors that materially impacted the winner of project.

When responding to Mike Spille, you always run the risk of being baited, but since we've not interacted in awhile, I'll respond.

From what I remember, it was a month long, grueling shootout where you had to pass and compete on various performance, scalability, and flexibility scenarios as well as the support factors Nathalie mentioned. We were also competing against other vendors like BEA, IBM, and even Jonas(the French Connection). AFAIK, we beat everybody in every criteria except for one, and in that case, we came in second (it was something like static web caching, I can't remember exactly).

BTW, this all happened, I think more than a 1 and a half years ago plus or minus a few months. It was so grueling, but it really boosted our confidence in how we compared against the competition. From that point on we started being much more aggressive in sales calls, JBoss forums, and public forums when the topic of performance and scalability came up.

I'll leave the financials to Nathalie, but the deal would have to be fairly large for us to put a month of resources into it. Since this deal we have tripled in size and more than quadrupled in revenue.

Yes, our confidence and aggressiveness is *actually* based on real numbers and a quality product.

how much due to ephemeral VC activity?

I don't know what you are saying, can you elaborate? AFAIK, our VC relations never had an effect on any sale.

This occurred with a several million euro RFP for the DGI (Direction Generale d'Impots) Copernic overhaul of all tax IT system applications for the French government. JBoss partnered with Atos Origin on this deal and Cap Gemini chose to use JBoss as their chosen app-server in this bid, without partnering with JBoss, Inc. They clearly told us "why should we pay you anything when we can develop our own JBoss competency center in house?"

Hi Nathalie,

I am aware of this contract: Jahia (www.jahia.org), my company, won the CMS/Portal refactoring part of it also for the French Ministery of Finance ... with Cap Gemini ;-)

The only think I wanted to mention is the fact that, if you do not have any license/maintainance revenue streams, the relationship with system integrators may become a bit more difficult to deal with: both of the companies want to sell as much professional services as they can as this is their business model and finally there may be sometimes some overlaps. So the SI which introduces you to a certain customer will always fear the fact that you will, one day, take his customer and/or resell all the services they were usually doing for other proprietary editors.

In the cases of Jahia, the think is (a bit) more transparant as, if there is a system integrator in the RFP(or many), we only play our editor hat.

But excepted such a possible overlap, I fully agree with you that it is difficult for a system integrator to bypass the (de-facto) editor. The question was more: how can you maintain some strong and good relationships with SI if both of the actors are reselling the same type of services and if the "editor" has all interests to sell as much services as he can?

The second question was more about starting a whole new open source project with a professional services business model without already having a huge market share. If I am not wrong, Marc created Telkel Ltd before creating Jboss Group and the years spent at Telkel were quite difficult (I am sure Rickard will not say the opposite ;-) ) befre Jboss succeeded. So the question is: is the professional open source business model efficient for all the open source projects whatever their size, recognition or market share is? Is it possible to invest a lot in a whole new open source R&D project without fearing that another SME will just compete with you by taking all the benefits of your code investment as soon as something is getting to work? Or is this kind of business model only possible for large successful open source project or distros which only repackage libraries they have not developed themselves?

To briefly answer your questions, I think any organization whether FOSS- or proprietary software-based has the potential for conflict between direct and channel (partner) sales. At JBoss we are not interested in being an SI or in competing with our ISVs. Many companies want to keep their SI as their main point of contact and the partner SI handles first and second-level support, with JBoss acting as the third-level. For those sales situations where channel conflict exists, it is simply bad business for a software company to steal a customer contact introduced to them by an SI. You may get one deal, but the cost is the larger sell-through relationship with that SI.

As for making money as a FOSS editor that sells services, you are correct that the early days of JBoss were not easy. It is not until a project matures and captures a decent sized market share that the Professional Open Source dynamics come into play. If it's mission-critical IT infrastructure, you're in the market that will pay for support.

I don't agree with the argument that open source support isn't a viable model. In the last 5 years, most of the projects I've worked required support. It's not that things are breaking all the time, but when it does break you want immediate response. I'll use a Rack server as an example. Rack systems have a high level of component failure, but once the system stable, it will generally run for a while (a few years) without any further hardware issues. When a hard drive, DIMM or motherboard goes bad, you want that fixed today. Waiting for a week is not acceptable for critical applications.

this is one reason why people buy Sun hardware. if I have a 280R and some hardware breaks, Sun will send someone out that day with a replacement part or the next day at the latest. In these types of environments, immediate response is critical. Small businesses don't need that level of service and shouldn't buy an expensive service contract. Whether an open source based company can thrive is another issue, but support contracts exist for more than one reason.

Eventually, if this industry is headed anywhere, noone will be deploying app servers. Server farms and grid computing will take care of that for you for the cost of a hosted solution which will be very low. <BR>

If you're lucky you wont know or care what J2EE server is running as long as its J2EE compliant and maintenance support issues will be handled by the service provider. <BR>

I cant see the profitability for companies to maintain app servers themselves when they clearly have no idea what an app server is, have no idea what support is required, or what is involved. I believe the software side of this will dry up completely within 5-7 years for the average company and app servers will be accessed just as leased services for "mainframe" (grid, virtual server) time.<BR>

If you're lucky you wont know or care what J2EE server is running as long as its J2EE compliant and maintenance support issues will be handled by the service provider.

So, i'm not so sure about this. I talk with people intimately involved with deploying application server technology every day, and when they complain about the app server product or company I ask them is why they don't switch vendors. The answer is that for one reason or another, they are locked in. Either because of in-house expertise, all-you-can-eat licenses that they would have to replace, some piece of 3rd party software that has a (real or imagined) dependency, prejudice, or the app server has a deployment model that their product relies on.

Nobody has ever said "we can use any app server we want." but if they are unhappy enough they will say "if that vendor keeps this up or that bug doesnt get fixed, we're going to switch, no matter how much it costs," which acknowledges the fact that even if the code truly is appserver-neutral, very little else is.

... I ask them is why they don't switch vendors. The answer is that for one reason or another, they are locked in. Either because of in-house expertise, all-you-can-eat licenses that they would have to replace, some piece of 3rd party software that has a (real or imagined) dependency, prejudice, or the app server has a deployment model that their product relies on.

I agree with you... It's hard to switch app servers, but I see signs that switching might get easier. For example, both IBM and BEA have announced support for developing on Geronimo, but deploying on their commercial products.

If my development process adopts the "develop on one, deploy on another" philosophy, then my lock-in should be reduced... Unless of course this "develop on one, deploy on another" process locks me into IBM or BEA's deployment tools.

... I ask them is why they don't switch vendors. The answer is that for one reason or another, they are locked in. Either because of in-house expertise, all-you-can-eat licenses that they would have to replace, some piece of 3rd party software that has a (real or imagined) dependency, prejudice, or the app server has a deployment model that their product relies on.

I agree with you... It's hard to switch app servers, but I see signs that switching might get easier. For example, both IBM and BEA have announced support for developing on Geronimo, but deploying on their commercial products.If my development process adopts the "develop on one, deploy on another" philosophy, then my lock-in should be reduced... Unless of course this "develop on one, deploy on another" process locks me into IBM or BEA's deployment tools.Sneaky ;-)

clearly there's a trade off. having experienced cross container issues, if one sticks to the stock API and avoid vendor specific enhancements, moving from one servlet or ejb container to another should be relatively painless. Of course, each person has to decide for themselves whether using vendor specific feature is worth the cost down the line.

there are cases even with servlet containers where the same application may have issues in a different server. the obvious example I can think of is request filters. When people started to implement support for request filters, one could interpret it two different ways: on redirect start a new filter chain, or keep the same filter chain.

I know some containers took the first approach, while tomcat took the second. So even if one sticks to the stock API, there are cases where the specification leaves enough room for conflicting implementations. I believe that has been fixed in most containers today. As long as one sticks to mature API and stock stuff, portability between containers is generally good. my 2 cents worth.

... I ask them is why they don't switch vendors. The answer is that for one reason or another, they are locked in. Either because of in-house expertise, all-you-can-eat licenses that they would have to replace, some piece of 3rd party software that has a (real or imagined) dependency, prejudice, or the app server has a deployment model that their product relies on.

I agree with you... It's hard to switch app servers, but I see signs that switching might get easier. For example, both IBM and BEA have announced support for developing on Geronimo, but deploying on their commercial products.If my development process adopts the "develop on one, deploy on another" philosophy, then my lock-in should be reduced... Unless of course this "develop on one, deploy on another" process locks me into IBM or BEA's deployment tools.Sneaky ;-)

clearly there's a trade off. having experienced cross container issues, if one sticks to the stock API and avoid vendor specific enhancements, moving from one servlet or ejb container to another should be relatively painless. Of course, each person has to decide for themselves whether using vendor specific feature is worth the cost down the line.there are cases even with servlet containers where the same application may have issues in a different server. the obvious example I can think of is request filters. When people started to implement support for request filters, one could

so, just to be clear, my point was not about vendor-specific APIs or implementations, but rather on non-code-related dependencies.

If you're lucky you wont know or care what J2EE server is running as long as its J2EE compliant and maintenance support issues will be handled by the service provider.

So what happens when when of your application developers mistakenly sticks something in the application that brings the hosted app server to its knees every few days?

There's simply too many things an application developer can do to destabilize an application that require actions on the app server in the short term to alleviate and lots of experimentation with it to fix for external hosting of an app server to be viable. Sure, the OS and JVM may will stay up. The app server may even keep on responding to requests. But how many users and the executives they ultimately work for care about the OS, JVM, or app server if the application isn't accessible.

I think where everyone is in agreement is that companies need to have access to people with expertise in the products they use, so the question is not one of "support versus no support," it's one of "internal support versus outsourcing."

Companies and individuals make the "how do I support X" based on a wide variety of factors:o regulation & complianceo geography & time zones o business criticalityo costo business preferenceo existing relationshipso competence

These are the same factors used to make decisions on whether to hire an in-house lawyer, mechanic, accountant, cleaning crew, etc, or to contract it out., or something in-between (hire managers, outsource staff).

If you go back to my original blog you'll see that I am actually saying that more support is going to be the commercially viable model for FOSS. My real beef is that the existing 24/7 support is not worth the price. It is expensive insurance for a low risk part of the infrastructure.

No no, they don't quote prices there. They used to at one point but they have apparently stopped doing that. But it does outline the support options available, and states "Three support levels are available ranging from 48 hour e-mail support to full 24x7 live support with 2 hour response times.".

The support brochure also shows how support has changed at JBoss. In the June 2004 powerpoint presentation it was written all in caps "NO PER CPU COSTS". But the brochure now says "several bands of deployment sizes are available all based upon number of CPUS utilized". There is also mentioned an enterprise option with no per-CPU cost which is just one fixed price.

The fact that the brochure differs so radically from the powerpoint presentation of a year ago would lead me to believe that the numbers in the presentation are definitely out of date. It'd be interesting to hear what they are today, but I'd be willing to guess that the "cheap" support that Bill refers to is the one where a response is guaranteed in 2 business days.

It's interesting to note that last year's powerpoint claimed "Staffed with the lead developers of JBoss Inc. Projects" and "No navigating through levels of escalation". Apparently this also has changed.

As a final note, it's interesting to see something buried deep inside the support literature:

5. Advanced Management and Monitoring – Gold and Platinum level customers have access to bundled and/or optional monitoring and management tools. Specific capabilities include Inventory Management for simplifying organizationof your IT assets; Administration and Control Management for scheduling configuration tasks and operations such as start, stop, and re-start; and Monitoring for receiving configurable alerts based on pre-defined thresholds.

It sounds an awful lot like JBoss is offering closed source proprietary software to its gold and platinum level customers. That's certainly one way to get people to buy support - offer the open source vanilla but develop extra tools closed source tied to support contracts.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.