Platinum Partner
java,open source,industry

The "Future of Open Source" Revisited: Added Value?

I have been reading through (and thinking about) this article on "the future of open source", I considered adding a couple of thoughts both personal and from point of view of a person that also has to make strategic technology and product decisions. As we have heavily been into using the NetBeans / Glassfish tool chain lately (and intend to keep on doing so for as long as possible), surely we are to some degree concerned by Oracle acquiring Sun. When deciding to go for Java EE, we also had a look at the Oracle product stack and, after all, made a conscious decision for Sun for a bunch of reasons, the fact that both products are open-sourced definitely being one of them.

As I already pointed out elsewhere, I think Sun made a bunch of fundamental mistakes about their open souce strategy which is causing some uncertainty right now, especially as far as governance of their open source projects is concerned. Surely there are good reasons for that, but yet, otherwise things eventually would be easier by now. Looking at this, we also so far made a conclusion on future decisions: Right now, we are looking into Apache Geronimo and ObjectWeb JOnAS as likely candidatese to replace Glassfish as Java EE servers (when / if Oracle does something making this step required) and, obviously, Eclipse as the IDE to go with (when / if Sun being acquired by Oracle might put an end to NetBeans as we know it now). No offense to Oracle, I see that most of the JDeveloper folks I know are kind and helpful people, and their Java EE stack also is pretty good at times.But, however, as an SME so far we always have been searching for partners (both related to hardware and software) we could handle. Sun did work. Oracle is way too big for that, from my current point of view. 

Plus, there is another issue about that: Adding value. One of the commenters in J.M. Arranz' article raised the question of paying for "value added" to open source software. I definitely agree, and I see this a valid and extremely important point. What is adding value to open source software? Buzzwory as it is, both here in our own environment and regarding our customers I see people more and more talking about what some use to call "bussiness-IT-alignment", having a more "pragmatic" look at technology: It's not hardware, software or software products that matter. It's IT solutions that matter, addressing a given business need, covering business use cases, providing value to the company. From this point of view, hardware is pretty "generic". For this domain we do have reliable vendors keeping our servers running, we simply won't have to worry about this. Likewise, we're using variants of the Debian GNU/Linux operating system on most of our servers for the same reason: We master this, and asides this it's just there, it works, we don't have to think twice. SQL databases and Java EE servers fall into the same category - they have to be around and do their work, and yet they are generic infrastructure for our own applications addressing our own business needs. The fact that there is quite a set of good to great open source technologies available here makes choosing this "generic" infrastructure rather easy...

But, however, I wanted to think about "adding value". What does add value to a product, value which we really would see as value, which we are ready and willing to pay for (and actually do at the moment)?

  • Strange as it sounds: Vendor independence is one of these values. From this point of view, we'd rather pay some company to provide us support for an open-source Glassfish or, maybe in near future, for an Apache Geronimo installment (which in the end would allow us to search for another vendor providing support for the same product given the need) rather than buying a proprietary full stack at Oracle or IBM.
  • Scalable operation support is one of these values, "scalable", here, meaning to make a custom balance between budget spent on support and benefit gained from it. In example, right now we wouldn't need to have an SLA including a 4-hour assured fix time in case of critical issues as our environment allows for compensating a fix even just next business day. Asides this, "scalable" support here also includes having a community at hand for getting (as well as offering) support on things which aren't critical in terms of time / schedule.
  • Developer support is an extremely valuable asset to have. As pointed out, business value arises from the applications deployed to the "generic" infrastructure, and creating these applications in a fast, robust, extensible manner is extremely helpful for quickly addressing changing business needs. What we experienced so far, Sun support did rather well at this.
  • Reliable, stable, verbose, complete documentation is an additional value to have. NetBeans, in example, might still have some weaknesses compared to Eclipse in some respects, but one thing's for sure: Documentation is excellent. There is a whole lot of documentation available on the website, there is a very extensive API documentation for platform developers, and there is a growing set of up-to-date books on both platform and IDE.
From this point, future seems clear to me. Vendor independence is an "added value" just to be gained from relying upon an open source application and paying someone to provide you with support. This kind of approach, however, just works while choosing a product which basically is open-source and not predominantly maintained by a given vendor. So no matter where we are heading if we eventually have to make a new decision, the general direction is clear: We will go for tools and applications developed by open source foundations or consortiums and search for partners to provide us with the set of "added value" left after evaluating our requirements against the budget available. And, completely not sure where things are heading for these projects, I still have some hope to, then, be capable of dealing with Glassfish or NetBeans again... at least, "Codehaus Glassfish" reads pretty good to me.
{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks
Tweet

{{parent.nComments}}