Listen to the podcast here.
Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions and you are listening to a sponsored BriefingsDirect[TM] podcast. Today, a discussion about the “Eclipse Effect.”
The Eclipse Foundation has grown in popularity for the past two or three years and really is on the cutting edge in de facto standards for development environments of major Java software projects, particularly among software companies themselves. To discuss this subject, we have Brent Williams, a Senior Analyst at KeyBanc Capital Markets. Brent has been a stock analyst for some 10 years. Prior to that, was a tools analyst at Gartner, and before that an operating systems and applications analyst at IDC. He has also spent some time as a developer. Welcome to the show, Brent.
Brent Williams: Well, thanks very much for having me, Dana. I'm glad to be here.
Gardner: You have a little bit of business to attend to in terms of your ability to discuss these subjects as a stock analyst. Can you go ahead and provide some clarity?
Williams: As part of our ongoing, “Keep Analysts Out of Jail program” and “Keep the Lawyers Happy program,” I've got to let you know that we may talk about publicly traded companies. My firm, KeyBanc Capital Markets, may have a relationship with those companies, including making markets in their stock, soliciting to provide them with investment banking services, or other forms of business relationship. On the other hand, you should also note that none of the companies that we discuss are ones that I hold or any members of my family hold any investment stake in any capacity.
Gardner: Alright. Let’s get into the meat of the subject: Eclipse Foundation. You have pointed out in some of the presentations I have seen that Eclipse is unique in that it straddles both business and technology. Describe what you mean by that -- and is this something that’s new? Have we ever really seen anything like the “Eclipse Effect” before?
Williams: What I meant by that was that Eclipse came along, taking technology that was developed commercially under the standard model at IBM, and brought it out to open source. Because of the nature of the tools business, the IBM sponsorship, and what this project was all about, it really attracted corporate developers.
If you go back to the early days of Linux, it was all individual contributors working on pieces of the project that were of interest to them. Eclipse came out as a fully finished piece of production-ready code. And, so it just didn’t evolve that way.
When Eclipse moved from a foundation or from a consortium into a really independent foundation that really had no material control from IBM, it was really set up to say: "How do we accommodate the business needs of all of these companies that are contributing code to this organization; and how do we do that to create a neutral playing field, because we recognize, many of these companies will be fierce competitors?"
That intentional accommodation of corporate needs was built into the organization from day one, and it’s been built into open source projects over time. And so, when you talk about the Eclipse Effect, it means that Eclipse has taken significant amounts of contributed corporate technology and has run with it, but it's also managed to accomplish a dramatic market share.
According to one survey I've seen, Eclipse is a tool of choice for about two-thirds of the Java developers in the world, and it’s coming up fast as a tool for many other platforms as well. So it's gotten tremendous market-share gains, which I think validates that the approach for this particular type of project really worked.
Gardner: Eclipse started out as an integrated development environment (IDE). It since branched out into some other areas. Are we really talking about the best of both worlds here in terms of commercial command-and-control development, as well as the viral and lower-cost development of the open source community approach?
Williams: That’s exactly it. Part of the way that they have been able to pull off this seeming contradiction is that they have a fairly loose project structure. In an operating system, by comparison, the Linux kernel all of the pieces are very tightly interdependent; and so, if there’s a bug or if there’s an integration issue between a couple of modules of the kernel, the whole thing comes crashing down and doesn’t work very well.
But in the Eclipse project, the technology is much more loosely organized. The end result is, that companies wanting to contribute a particular piece to Eclipse can go off and build that in a conventional structure, then contribute the product to open source. They don’t have to worry so much about dependencies with other projects. So, they can use a standard structure to get their area or their projects built, and then go and take advantage of open source. When you come out with finished code, we are actually starting to see the community come in and do enhancements off these more monolithic contributions from the corporations.
Gardner: As we have seen swift adoption, there seems to have been some tipping point, or critical mass, where the interdependency of those contributing and those using, starts to well up -- and there is more opportunity for people to contribute, which makes it more valuable, which brings more people into the community, which then prompts them to contribute. Is that what we are seeing: a powerful adoption benefit here?
Williams: I think we are seeing an inflection point, and that’s come up in maybe the last 12 to 18 months. That’s exactly the sort of virtual circle that you are describing. What's different, maybe just in degree or maybe in the way that it’s accomplished, is that the structure that Eclipse brings to bear makes it very, very easy for people who are focused on certain types of things; and are what they refer to in Eclipse as "add-in providers."
They maybe unlock some particular piece of hardware, or a gateway to older legacy data -- something like that. They can fit into that project or into that environment very effectively, perhaps more so than in other major platform architectures. That's really been one of the factors that’s helped this inflection point ramp up so fast, because the more focused add-on providers you can get out there with access to RFID readers or bar-code scanners, the more commitment they’ll have for that platform, and the more valuable the platform becomes.
Gardner: Now, an integrated development environment -- this is not a trivial piece of software, this is not even something on the same level of, say, a Web server. It traditionally required a great deal of research and development and effort by companies like Borland and Microsoft, who have been leaders in tools. For this to happen in this environment and for this inflection point to take place, does it portend a real shift in how software is developed, or is Eclipse a one-hit wonder that will probably not be repeated. And if this is something that is a harbinger of more similar types of activities to come, what does that mean in general for the software business?
Williams: Well, let me answer these two pieces in reverse order. We are entering a point in the software business where, if you look back to the height of the Internet bubble, there was a lot of stuff coming to market, that was features disguised as products, disguised as companies. Basically any somewhat-decent idea that was kicking around inside of somebody’s head went out and got funding, whether or not it was a sustainable product, or even company. When it got funding, it went public.
And so, what you had was a trough of despair for few years after that, when the idea file had been drained of even average ideas. There weren’t any really new technologies coming to market. We’re at a point now in the software business where we’re on the rebound from that drought of good new ideas; and we’re starting to see that broadly in many areas.
So, I think that, yes, development tools fall into one such area. It's been a fairly stagnant market until the last couple of years or so, since Java began to attain prominence in the mid-1990s. A lot of Java development environment decisions were made. Things went fairly quiet until Eclipse came along, and that has started to revitalize it. In general, we are in a period where there’s lot of good new technology coming to market that people are taking a look at. You are starting to see people actually put their dollars behind buying some of this technology, which they weren’t doing in the 2001-2003 time-frame. And now I have completely forgotten your question.
Gardner: Is this a one-hit wonder? That's to say, is what's happened with Eclipse unique, or are we seeing a larger shift toward open community development frameworks that are embracing the tipping effect that happens where adoption and contribution begets more adoption that begets more contribution? And does this happen outside of a traditional licensed software business model? And if so, what does that portend for folks like Microsoft, IBM, Oracle, and SAP?
Williams: There are a couple of interesting things going on; and I have been around development environments for a lot of years. As you mentioned, I covered development environments in the early nineties at Gartner Group and left to go to Wall Street just as Java was starting to become prominent.
The thing that’s happening is that the integrated part of integrated development environments is really undergoing change. If you look back historically to Visual Basic, Borland, or some of the stuff that Sun Microsystems has acquired or any of these development environments -- PowerBuilder, you name it -- they were all tightly integrated with a single vision and a single way of doing things. If you wanted to do a re-think of that, it was all-or-nothing. If you didn’t like the way that, let’s say, Borland’s Delphi handled database access, well, you had to just sort of live with what they did, or you had to go to a completely different tool, which would probably have faults of it own.
These were very monolithic, and it was difficult to integrate, say legacy 3270 access or something like that to the development environment, but you had to buy into a particular way of doing things. Then, you were at the whim of the vendor to do that. Eclipse has changed that a lot. Java had to a certain extent, but it was still proprietary vendors. Eclipse changes this dramatically, because the various bits of the IDE are very much decoupled and almost dis-integrated. They can be swapped out, reassembled, and reorganized much more flexibly than any development environment that I can think of at the moment.
If you don’t like something about Eclipse, you have the chance to go out and replace it and end up with a more best-of-breed solution. So the end result is, that a development environment or development strategy based on Eclipse can evolve over time more smoothly -- unlike: "Okay, I get PowerBuilder in here in client-server era, then the Internet comes along. PowerBuilder’s Internet support has taken them a long time to get out there, and then they don’t really make the curve very well. So, you have to just dump PowerBuilder and go on with something else." That's not a very smooth move forward -- in fits and starts every five or six or seven years.
Gardner: So, I guess we have now gotten to the point where the framework that developers are comfortable with, as long as it adheres to Eclipse, gives them an opportunity to do what they want to do, in the way they want to do it and yet not feel that they are outside of the larger environment that allows us to be compatible with other frameworks and other activities by other groups and developers. Is that fair?
Williams: That’s absolutely right. Even these days, whenever somebody uses the word framework, I find myself gritting my teeth unconsciously. If you hark back, I think this is really fallout of the mainframe era. If you hark it back a decade or so ago, a number of folks were talking about frameworks with a capital “F," and these were really complicated. I mean, you had everybody from Anderson Consulting -- where they called them methodologies, but conceptually equivalent -- and all the big system integrators -- you had guys like IBM, EDS, and a bunch of other folks -- talk about frameworks.
The idea was that if you bought into our one, big framework -- the one, true way to build software -- then your productivity would go through the roof, and life would be wonderful. The old style of frameworks was just another kind of religious buy. You had to buy into this whole way of doing things before you could buy the product. That was the same problem we had with early client-server tools, with those monolithic closed-development environments like PowerBuilder and stuff that I referred to.
Fast forward to today. Because of the open, loosely coupled approach to Eclipse, if you don’t like whatever framework is at hand, if you want to change to some other framework that supports the platform, you could do that. You don't have to heave out all your code. You don't have to start from square one. It gives you what frameworks can offer in the best of circumstances, but it does it without having to make you start from scratch to change frameworks.
Gardner: So, we can clearly see some technology benefits -- agility, flexibility and openness -- but there has to also be some impact on the economics and business of software. I suppose in the past there was a bit of a quid pro quo or at least a relationship between the tools, which were often sold at cost, or even a loss, because they tied the application and developer to a platform; and the monetization happened in that volume selling of the license for the platform.
Well, now that -- as you pointed out -- we are loosely coupled, we are not tied to a specific platform, how does the modernization happen? What does this mean for the folks who are making a transition from licensed software tied to the platform to this new era where we have got loosely coupled Web services, frameworks, and developers who are really not even thinking about what platform their code might be operating on?
Williams: The last thing you said hints at it the old model where you used a low price development tool as kind of a free "vial of crack" to get them hooked on your platform. That model only worked in an era where there weren't decisions already cast in stone about platforms. Right?
In the early days of client-server that model was brilliant because people hadn’t really made a decision about, "This is our platform for client-server type stuff." It was all new market, and that’s the right way to reach that market. On the other hand, saving somebody a thousand dollars, or whatever it is, on the development tool license, when the platform decision is already made, it’s really not going to do much for you. The cost of moving from UNIX to .NET is in no way going to approach the economics of free .NET tools, which is not going to close the gap.
It’s like if you buy a new car and you get free gas for a year. That might sway your decision. But if you buy a new car and you get those little things that screw on the tires to keep the air from leaking out free for a year, it’s probably not enough to make a difference. So, platform decisions are already made. Folks like IBM and a lot of folks from the Microsoft universe are going out there and saying the next opportunity is not to get people on the platform, because everybody has already got a whole mix of platforms.
We are no longer playing for, “Hey, we will get you on our platform. Our platform will solve all your problems. You will throw out all your other platforms -- and we’ll have a monopoly.”
Gardner: The old rip-and-replace methodology.
Williams: Yeah, rip-and-replace, and give all of your business to a single vendor. I don’t think that’s going to happen. IBM, for instance, is tremendously interested in Eclipse, because its flexible architecture allows it to surface capabilities from legacy systems into Internet Web-based applications.
You can make better use of assets that you have, and the end result might be that, instead of just trying to keep the mainframe business growing at a slow level of growth, IBM might be able to accelerate the growth of mainframes. That's not because that’s becoming a monopoly, but just because people will store more data on mainframes because they can get to it easier -- and they can get to it easier because they can integrate it into any application -- Web-based, client-server, whatever -- because of Eclipse.
Gardner: Perhaps one of the business impacts here is that a developer and an architect have a lower risk with Eclipse because they have both backward as well as forward compatibility with platforms; and in having that ability to be compatible, both to the past as well as the future, this gives new life blood to some of the older sun-setting platforms and reduces the risk of having to change framework and tools, should you want to move ahead to a new platform.
Williams: That’s exactly right. This is just another slant on what I was suggesting earlier about Eclipse taking you from having to live with what you’ve got until a revolutionary change in development environment comes along. Eclipse supports incremental evolutionary change more effectively, allowing customers to take advantage of those technologies, and allowing vendors to make money supporting that.
I think it’s a win-win situation when IBM has extended capabilities of some of the non-relational databases like Information Management System (IMS), so that they can capture what's happening in real time and generate streams of events to be pushed back out to a Web-based application. And, that’s a new capability for IMS. With a development solution that allows developers to take advantage of that on the Web-side -- since there is not that much IMS expertise out there in the world these days -- when you can get to that stuff easily, you can take advantage of your existing legacy code in a new way.
That’s usually great economics for the customer, and IBM can sell more IMS licenses, which, given the amount of R&D they spent keeping IMS maintained and improving it, creates a huge win for IBM. It really does give win-wins to both the customer and the vendor.
Gardner: There are some other trends that are bubbling up in the industry that have some impact here. I'm thinking about Service Oriented Architecture (SOA). You might have different applications running on different platforms, and not only can you take advantage of that from a development perspective using Eclipse, but on the runtime and operations and production side of things, you can expose those services and suddenly you have an opportunity of continuing to operate for a longer period of time for a lower total cost of the lifecycle of the application and platform.
That also raises the issue about where is the next value-add. Is it in the integration, and is there another level of tool that you’ll be depending upon to stitch together and orchestrate and composite these applications? And, not to be too long-winded, but what does Eclipse bring to that level of tool; how does Eclipse impact SOA?
Williams: Well, I think this evolutionary approach is certainly very much in line with SOA. Instead of going out and ripping out huge chunks of systems just because there is no other way to integrate stuff effectively, now I can surface bits -- not all at once, but over time -- that are important and I can effectively hook them all together in a way that’s already platform independent.
SOA is really about using incremental evolution of legacy code to try and produce revolutionary results, being able to do business in a far more productive way that I had in the past. Everybody knows SOA is a big deal; its going to take a long time, but it is a big deal.
Eclipse helps because -- I think you gave it away in the use of the word "orchestration" -- when you are building services, you might use one development approach to write code, with Java based IDE, which Eclipse is already very good at, and to stitch those things together, it might be a different team of people that are stitching these services together, and they are using an orchestration approach.
Having that work inside the Eclipse umbrella is very attractive to customers because they don’t have to have a completely separate product that has nothing in common with the Java IDE. The notion of business process management systems, or workflow management systems had been around for a while, but they’ve all been standalone products from different vendors than your ‘C’ Compilers or Java Tools guys or your database guys.
If those guys can operate under Eclipse with their own unique vision of workflow and orchestration, and the software development environment happens there under the Eclipse umbrella, then it’s a lot easier to have all those guys coordinating their efforts more effectively. The tools can all interface more effectively. That gives you more reliable applications, and it gets it done in less time.
Gardner: Perhaps some of the overview impact here is that the vendors are going through some transition, facing some challenges in terms of a shifting business model, but there should be plenty of opportunity for them to monetize and find value and bring more business benefits to their end-users over time.
I suppose the biggest winner here, the win-win, is for those enterprises that have reduced risk, have an opportunity to gain agility and can finally bring somewhat of an end-to-end understanding of benefit or control over development. Or, am I over-hyping some of the benefits to the end-user enterprise here?
Williams: It’s one of these things where there is enough interesting stuff going on, that I don’t think you are over-hyping. The over-hyping zone is in promising how fast this is going to go. We are now at a point where, for the first time, we can achieve these goals; that’s great news.
Just saying it’s possible is quite legitimate; saying that it’s going to happen in a short period of time -- whether that’s six months or two or three years -- that’s probably a little over-hyping. You certainly didn’t do that. I think that you are absolutely right.
The enterprises that can get to this can get themselves on a platform that will support incremental evolution of development processes. So, you don't have to go in fits and starts every five years, like you do with, a silo-based tool. Organizations that can do that will win over the long term.
So, yes, this is a reward for the clever. But interestingly, we are just talking about linear extensions of what people understand Eclipse to be about today. The other thing that we are starting to see is effects where companies are able to use Eclipse support in their products in ways that are bolstering their business and that aren’t terribly obvious. We have seen this in the case of, for example, Actuate which sponsors BIRT, which is one of the more popular tools, a Java Reporting Engine that can be embedded in your Java app. It’s part of the Eclipse platform.
Gardner: Right.
Williams: What’s interesting is that the Actuate guys went out and they -- as we talked about earlier -- used a very standardized command-and-control development approach to build the first two releases of BIRT, got it out there in community, and now they are building a community of developers around it. They are working in a more classical in-source fashion.
Actuate’s hope was to use the project to give them a stream of revenue for low-end business intelligence. Actuate’s problem had been that they were pinned at a very high end of the market, like Lamborghini is pinned up at the very high end of the car market. It’s hard for them to sell down into a more mass-market configuration without destroying their brand.
Actuate had been kind of the Lamborghini of business intelligence, and other companies that were more mid-market had outrun them. So, they went and had an Eclipse strategy, launched the BIRT product, and did a lot of good stuff as how they built their community. Now what they are finding is that it’s actually helping them sell the high end Lamborghini product, which isn’t open source. The end result is that having the Eclipse product not only helps them address a new market that they weren’t able to reach, but it actually helps them address their existing markets even more effectively.
Gardner: So, the business benefit for the vendors is that they can reduce their overall R&D spending on some of their new products by -- after a few iterations -- bringing it into a community; And, they can get the benefit of that larger community adoption becoming aware of their other commercial products and/or perhaps have additional monetization around service support, maintenance, and so forth.
Williams: Exactly. And that's a very unexpected kind of result -- the idea that they are getting rewarded for being a part of Eclipse on stuff that even isn’t directly Eclipse-related revenue. I think you'll see other people out there looking at using Eclipse, perhaps as BEA Systems has done with their Beehive project, contributing code to Eclipse to help achieve other strategic aims within their businesses than just, as they say, driving a support revenue stream from Eclipse-related stuff, as they do for their current projects.
Gardner: So, in effect, the Eclipse Foundation and community has provided a viral marketing benefit to these vendors, that they would have to spend a great deal of money attaining on their own -- with their own direct-sales force trying to create their own community and their own lock-in around a proprietary stack.
Williams: That’s exactly right; and this becomes a benefit to customers as well; as vendors start to use the interest, the market share, and the mind-share that Eclipse has among the customers, then they start to find these non-obvious business models.
That accelerates the momentum around the platform still further. The end result to the vendor community is that no longer is it a forward-thinking, bold, risky move, but rather an interesting one, to join Eclipse and contribute stuff to open source. It becomes just what you do for some portion of your business.
I am not saying for a second, that all code that’s currently commercial is going to open source. It's probably not. But, like the BEA guys have done, the Actuate guys have done, and some other folks have done, contributing some portion of your code asset to open source is going to provide dividends to you, the vendor, and its going to provide huge dividends to the customer community.
Gardner: I suppose the net takeaway here is that Eclipse Foundation has given a community and a viral distribution benefit to the vendors, the corporations and the users. They have had significantly reduced risk about making choices around platform.
Williams: That’s exactly right.
Gardner: That sounds like a nice combination.
Williams: What's interesting is that this is a very unique combination at the moment. But if you look at other areas, one of the things that have happened is people in industries outside of software are looking at what Eclipse is doing and they are saying: "Hey, this is really intriguing."
So, a couple of success stories include Procter & Gamble and a thing called InnoCentive, which was started by Eli Lilly, the drug manufacturers, to do essentially outsourced community-based science or product research and development. The exact methods are somewhat different than the way Eclipse works.
All of this was inspired by the work that the Eclipse Foundation has done as an organization, as a way of bringing companies that are often competitive together to do collaborative innovation among users, vendors, and competitors, and to have it work out well, so that everybody has real economic opportunities. The proof that Eclipse is actually doing this is in looking at how this notion of collaborative innovation is spreading to industries that have nothing to do with software.
Gardner: So, the Eclipse Effect is not, by any stretch, through – it’s just moving outward from its IT roots.
Williams: That’s exactly right. The Eclipse guys, as near as I could tell, are fairly sharp at understanding what's given them success. They've got a ways to go, but I think, you can actually see, without being excessively hype-driven, that in part because of Eclipse, and in part because of the attractiveness of open source in so many areas, that collaborative open innovation becomes an important way of doing all kinds of things.
It's not going to be the sort of circus show like, “Oh! Look, there is a bunch of hippies; they think they can write an operating system that will take the market share from Microsoft.” That was the perception around six or seven years ago.
Now, there may be some hippies involved -- many of them are on the payroll of these vendors, and they are already taking a lot of share from Microsoft -- it's no longer a freak show. This collaborative innovation model with a structure that allows competitors to have an even playing field and maximize those opportunities for vendors and benefits to customers, is just going to be a way that innovation happens in this increasingly globally outsourced to off-shore kind of world.
Gardner: Brent, I want to thank you very much for joining us here. We have been discussing the Eclipse Effect in community innovation, how it began with development tools and extended into other areas, and perhaps beyond IT altogether. Brent Williams is the Senior Analyst at KeyBanc Capital markets. Thanks very much for joining us here today.
Williams: Well, thanks very much for having me, Dana.
Listen to the podcast here.
Transcript of Eclipse Fouundation-sponsored BriefingsDirect podcast, recorded June 7, 2006. Copyright Interarbor Solutions, LLC, 2006. All rights reserved.
No comments:
Post a Comment