How to convice your Boss to choose JBoss
Jun 2nd, 2008 by sharps
Have you ever been in that situation where you’ve quickly developed your cool new app using JBoss only to be told by your boss that you have to port it over to some other vendor’s dinosaur of a run-time because it’s the “corporate standard” ?
Does it frustrate you that your IT department standardized on a run-time platform 7 years ago – a platform that’s big, slow and lacks the innovation you have free and open access to via JBoss. If so, read on. I might just be able to equip you with the information you need to convince the powers that be to review those decisions and make a better choice.
Organizations are increasingly building their IT infrastructure on Open Source; though some concerns still remain often perpetuated by some of the following myths :
Myth 1 – Open Source is just for Hobbyists and isn’t ready for Business Critical, Enterprise Deployments
This may have been true 7 or 8 years ago; but even then only a little bit true. Here are some facts to consider. i) The Web – the largest piece of IT infrastructure on the planet owes it’s success to Open Source; without Open Source the Web wouldn’t exist; ii) A recent Forrester report made it pretty clear that JBoss in particular is better quality than some existing, proprietary, large vendor products; iii) Most of the incumbent proprietary products (especially those based on Java) use a large amount of open source software already – ie. they’re a hybrid of open and closed technology.
Myth 2 – Open Source does not provide professional, mission critical support
A number of pure-play Open Source companies have attempted to build a support business around technology for which they neither have a controlling interest; nor sufficient expertise to actually “support”. Practically speaking – in open source – trying to fix a bug that your customer thinks is important requires you to have developers deeply engaged in the Open Source communities in question. Not only is Red Hat one of the largest contributors to Linux; it also maintains active commitment to many Open Source projects on JBoss.org, Hibernate.org, Seam.org, Apache and OpenJDK.
Red Hat not only provides mission critical support for Open Source but excels at it. When technical support is your most important core competency rather just a cost centre – you have to be the best in the business. Vendors with more traditional business models (ie. you pay for the software up front and pay a little extra for support) aren’t compelled to excel at support.
Myth 3 – The licensing issues related to Open Source means we can’t take the risk
Open Source licenses are confusing and you do need to be educated to understand the responsibilities and risks associated with them; just as you need to read EULA’s for traditional shrink-wrapped software. You do that right 
Myth 4 – What if I choose an OSS technology and the authors stop work on it – I don’t want the maintenance burden
Hey – proprietary technologies fade away and die too ! The Open Source model acts as a Darwinian Filter – bad technology that has little or no practical utility dies; and dies pretty quickly. Because of the natural transparency of OSS there are many indicators you can look out for – activity on forums and mailing lists; pace of change (eg. release cadence); diversity of community (ie. is it dependent on one individual; one commercial organization ?); adoption – many OSS projects track and publish their download stats.
Myth 5 – Only huge, well funded proprietary companies can afford the innovation required to compete.
Over the last 10 years the open source movement has continuously demonstrated that open source collaboration is the best way to fuel technology innovation. It’s no accident that many of the companies that you’d typically associate with innovation are also strong advocates and users of Open Source – Google, Facebook, You Tube, Yahoo, Twitter, etc. From my experience – it is often the case that the pace of innovation is often too fast, giving downstream commercial companies the advantage of selective innovation – ie. they only have to take the best ideas and often have a choice of solution for a particular problem.
What other concerns do you run into ? Leave a comment and share them with everyone else and I’ll try and find an answer.
You didn’t cover the “it doesn’t scale” excuse that I keep on getting from my CIO.
@Josh, I assume you’re talking about the scalability of the product ? – if so, which areas of JBoss do you think need most attention; and who do you think your CIO thinks sets the bar on scalability ?
- Rich
[...] : http://blog.softwhere.org/archives/170 [...]