Archive for the ‘Open Source’ Category
One Big Step for EclipseRT
The future of Java technology in the enterprise rests with its rapidly evolving ability to regain its original promise of lightweight, flexible and dynamic application development and deployment. In other words, the faster Java gets to the stackless stack, the brighter its future will be. As James Governor said in his seminal article, “component-based development is a common idea, but component-based production is a whole different ballgame.” That has been the vision of the EclipseRT project since its inception: the ability to support deployed runtimes which use only those components actually required by the applications at hand. This is an inherently service-based approach, and one which has seen rapid adoption by enterprise Java and Enterprise Service Bus vendors.
SpringSource has long been one of the most visible and vocal leaders of lightweight, componentized Java runtimes. Today, they bring that leadership to Eclipse. The Virgo project proposal brings to EclipseRT project a key component (no pun intended) required to provide a complete offering of OSGi-based runtimes from the Eclipse Foundation: a complete module-based Java application server designed to run enterprise Java applications. Based on SpringSource’s dm Server, we believe this project will increase the momentum of the enterprise Java developer community under the Eclipse umbrella.
The past couple of years, “establish Eclipse runtime technology as the leading open source runtime platform” has been on the top of the list of the strategic goals of the Eclipse Foundation. The recently announced Gemini project — and now Virgo — go a long way towards realizing that vision.
You can read more about Virgo on Adrian Colyer’s blog post.
[Revised to fix broken link to Adrian’s post.]
Collaboration Is Just Good Business
Last week at the Open World Forum, I had the pleasure of attending Michael Tiemann’s talk on the “Road to the Digital Recovery”. Michael kindly summarized his key points on his blog.
The most interesting sound bite from Michael’s talk was his estimate that $1 trillion is wasted every year in ICT spending. His logic is:
…18% of all applications are abandoned before ever reaching production, 55% are “challenged”, meaning they are either late, missing key functionality, buggy, or some combination of the three that results in measurably degraded performance. Back when this study was done, the scope of the analysis concluded that $78B/year was being wasted by US CIOs on “bad software”, but that is the tip of the tip of the iceberg: with global ICT spending over $3.4T USD in 2008, money wasted on “bad software” now exceeds $1T USD per year.
I actually think that the reality is worse. Much worse.
Michael’s conclusion is based on the number of projects which fail to accomplish or only partially accomplish their stated objectives. Everyone in the software industry knows that these types of failures are a simple fact of doing business-as-usual. The proposed solution is to lower the percentage of complete or partial failures by improving the quality of the software being built through using open source processes and techniques.
While I have no disagreement with that conclusion, I think that it is missing a huge part of the problem, which is that we all collectively waste massive amounts of human and commercial capital by building too much software. The sheer amount of wastefully duplicated effort endemic to the ICT industry is staggering.
Note that I am not referring to the software which provides companies any source of competitive advantage. I am referring to the software infrastructure which every company needs to merely operate in their particular industry. In every single industry you will always find some amount of software required by 100% of the players, for which 0% get any sustainable or even measurable competitive differentiation.
For one example, imagine the scenario where a new government regulation in the (say) insurance industry requires all of the companies in that industry within that jurisdiction to implement a new set of procedures. Pretend that there are 30 companies impacted. Even if the implementation project within each of those 30 companies was executed flawlessly, the wastage is 30x, because none of those companies achieved any customer differentiating value from their efforts. Multiply this scenario across all of the companies in all of the industries and the wastage of human effort, skill and imagination is depressing.
In my view, the future impact of open source on the ICT industry is not simply to make software better quality. It is to reduce the amount of wasteful effort squandered on implementing and re-implementing and re-implementing yet again the same bags of stuff that our current corporately-silo’d development structures require.
Open source communities such as Eclipse, Apache, Linux, et al offer enormous potential cost savings to industry. By establishing the licensing, IP management, governance and development processes to enable cross-company collaboration, these communities open the possibility that much of the “operating systems” of various industries could be built and shared. This will require some cultural shifts, but I predict that the business and economic rationale will inevitably drive companies in this direction.
Welcome to the EPL
A bit of good news for the Eclipse Public License this morning comes from Intuit, which announced that their community site code.intuit.com will be using the EPL.
Intuit had previously decided to use the Common Public License, but when we pointed out that it had been superseded at the OSI by the EPL, they agreed that it made sense to go with the EPL. It turns out that some of the links and pages at the OSI had not yet been updated, and thanks goes to Russ Nelson for fixing those quickly!
All-in-all a good outcome for the EPL. It’s great to see the increasing adoption of our license by the broader open source community. It is now the license used by the Topcased and Symbian communities as well as a growing number of projects on code.google.com and sourceforge.
EPL ~= ASL
Boy, am I on some kind of blog binge this week. It’s amazing how a few weeks without travel helps.
Dana Blackenhorn wrote a piece earlier today discussing Matt Asay’s article on why the Apache license is better than the GPL. In his article, he states the following:
If your company wants to release its own code, and control that code, if open source is mainly a marketing concept to you, then a BSD license such as Apache or Eclipse makes perfect sense.
Dana’s statement makes an error that I have seen repeatedly. Namely, that the EPL is a “BSD-style” license and is therefore similar or equivalent to the Apache license. This is just plain wrong. And it worries me that a long-time open source observer such as Dana would make this mistake.
The EPL is what is sometimes referred to as a “weak copyleft” license. It most certainly is a reciprocal license in the same way that the LGPL and the MPL are, for example. (The European Union describes the EPL as a strong copyleft license, in its paper describing license compatibility with the EUPL.)
In our view, the copyleft provisions of the EPL gives our community the best of both worlds. Yes, changes and modifications to EPL-licensed code need to be contributed back. This helps ensure that everyone involved is incented to make their contributions back to the platform, and encourages community building. But at the same time, because the EPL (a) does not define simply linking to it as creating a derivative work and (b) allows re-licensing of binaries under commercial terms, it encourages commercial adoption.
Licenses Matter
I’ve been thinking about posting on this topic for a while, and recent posts by Greg Stein and Eric Raymond have finally motivated me to get off my butt and git ‘er done.
As I mentioned recently, the EPL is on a bit of a roll at the moment. And that is a very good thing. However, what I find interesting is that – and this is implicit in the words of both Greg and Eric – is that many in the open source community believe that there are only two interesting positions in the licensing debate: GPL or BSD/Apache. A position which I believe is just plain wrong.
Here is the reason: business models are driven by licensing models. And there are many more business models under the sun than those supported by only those two bipolar licensing positions. In particular, “weak copyleft” licenses such as the EPL are great licenses for those who want to build a ubiquitous software platform with a commercial ecosystem. That is because it allows for commercial licensing of products built on top of EPL-licensed code while also requiring modifications to the platform itself be contributed back to the community. This balance is particularly useful for companies and entrepreneurs that want to create industry platforms.
Of the two, I would have to say that Greg is the most wrong, because he bases his argument on the notion that developers should pick their license based on their personal philosophy. And apparently developers only have personal philosophies that fall into either completely permissive or completely free, with nothing in between. He got it particularly wrong with his closing comment:
Middle-of-the-road licenses like MPL, EPL, and CDDL are wishy-washy. They can’t decide to be permissive, or to maintain Freedom. Choose a philosophy.
Companies and (many) developers do not pick licenses based on a philosophy. They pick them based on their desired business model. I am certainly willing to agree that some people are not interested in thinking through the economic results of their choices. I’m not willing to agree that applies to everyone.
I agree with the content of Eric’s post because find Eric’s economic arguments quite persuasive. I do believe that open source software production is more efficient. But I do not expect that commercially-licensed software will disappear for a very long time, if ever. Personally I believe that the eventual steady state is one where open source platforms provide a commons of infrastructure that supports a wide variety of commercially licensed software and content. However, in one of his comments, Eric pointed to the BSD as the “classic choice”. I would assert that the EPL and similar licenses provide equal, if not better, benefits.
I am a big fan of rational choice economists such as Steven Levitt and Tim Hardford. EPL-like licenses send the correct economic signals to rationally incent the behaviour that I want to see: commercially profitable ecosystems built on top of vibrant open source platforms.
Life at Eclipse 