Monday, June 26, 2006

Transcript of BriefingsDirect Podcast with Product Managers from BEA and Wind River on the ‘Eclipse Effect’ on Large-Scale Software Development

This is a transcript of an Eclipse Foundation-sponsored BriefingsDirect podcast with Dana Gardner, recorded June 13, 2006.

Listen to the podcast here.

Dana Gardner: Hi, this is Dana Gardner, principal analyst of Interarbor Solutions, and you’re listening to BriefingsDirect[TM]. Today, a discussion about the impact of Eclipse on the development market; taking a look at ISVs, those large vendors that are using Eclipse.

From industry reports, Eclipse these days is being used by two-thirds of Java shops. It’s really taken this market by storm over the last two years. And here to talk about their experiences in that are representatives from two major software vendors. First, from BEA Systems, Bill Roth, the vice president of the BEA Workshop Business Unit. Welcome to the show, Bill.

Bill Roth: Thank you.

Gardner: And also from Wind River, Steve Heintz, the director of product management for developer technologies. Welcome, Steve.

Steve Heintz: Good morning, Dana.

Gardner: As I mentioned, the ramp-up in the use of Eclipse as an [integrated development environment] IDE commonality for developers in both enterprises as well as [independent software vendors] ISVs, has been remarkable. Can you tell us, Bill, a little bit about how BEA became involved with Eclipse?

Roth: Sure. It helps to go back through a little bit of history. As many people know, we had our own IDE and were doing our own investment in IDE technologies throughout the early part of 2000 up until 2003.

It became clear as we moved into 2004 that Eclipse was taking developers in our target market, the Fortune 2000, by storm. It was in every account that we went into. As a result of that, we made the decision to move into Eclipse for two reasons … three reasons, actually.

First was that it clearly had a market presence. Second, it allowed us to leverage open source while contributing the important things that we thought needed to be added. And third, we finally became convinced that the foundation was independent enough from IBM that we could have some legitimate sway. Those were the things that helped move our decision to becoming a strategic member and a board member of the Eclipse Foundation.

Gardner: Has this experience worked out, in your estimation, according to what you expected?

Roth: Absolutely. In fact, it has exceeded our expectations in some regards. The governance processes, for example, are fair and balanced. Open source is generally a meritocracy. And so, we’ve been given our fair shot both in the [Eclipse Web Tools Platform] WTP project, where we have a number of committers, but also at the board level, where we actually have elected a committer representative to the board. That’s Tim Wagner.

Our ability to make valuable contributions in both the JDT, the Java Development Tools Project, as well as the Web Tools Project, says that it met or exceeded our initial expectations.

Gardner: Has Eclipse Foundation actually had a business benefit in terms of reducing your costs of development, simplifying through some integration and extension points what you would have had to have done, perhaps, on your own?

Roth: Yes. There have been a number of business benefits from my perspective. As someone who oversees the sales, production, and operations around our tooling business, the business benefits are several-fold.

Number one, there’s a bunch of people who were building an IDE that I can now retarget to build features to make developers’ lives easier. The joke I always use is, Eclipse is how BEA makes the most of IBM’s research dollar. Now, that’s a bit of a joke.

Gardner: This isn’t your first time, right?

Roth: Of course not. The second benefit is that it gives us access to a much broader market, and the last numbers I saw is that in the Java Developer Tools market, Eclipse or Eclipse derivatives have a 58% market share.

In any kind of open-source industry where you’ve got multiple vendors, it’s almost unheard of. And the other benefits include our ability to deliver software more rapidly. The Eclipse update model, which is really one of the under-discussed pieces, allows me to -- rather than be on an enterprise software cycle, where I’m delivering every 12 to 18 months -- deliver software every day if I have to. Those are really the three business benefits that I see from my position.

Gardner: BEA is a provider of development and deployment strategies and runtimes and solutions for large enterprises -- high-performance, high-complexity applications -- and so it’s clear that Eclipse is giving some benefits there.

Perhaps in a different direction, segueing over to Wind River, where their platform and tools target embedded development, a whole different marketplace. Steve, what’s been the Eclipse impact or the Eclipse Eeffect, if you will, in terms of how Wind River has adjusted to this marketplace?

Heintz: Well, when I take a look at our market, we’re dealing with a different language than Bill’s [BEA] customers. We’re dealing with customers that are developing C and C++ projects, usually using Linux on a target-embedded device or a real-time operating system, like the VxWorks on a target-embedded device.

Our customers are in the aerospace and defense segment, the consumer-device segment, or networking equipment. Most of those customers demand not only tools from us, but very specialized tools specific to the type of product that they’re building from various partners out there.

For us as a single company to go and make all of those partner relationships and all of those integrations it was too time-consuming. It was actually impossible for us to manage all those integrations ourselves. That’s one of the best things that Eclipse brings to the table for us. There’s an open API model, and there are a lot of partners in our investor segment who already have the integrations done. So we get to take advantage of a much larger part of an ecosystem than we could develop and mature on our own.

Gardner: Now, this notion of faster time to market, that’s a big factor in Device Software Optimization (DSO). In your marketplace, can you give us some examples of how your clients and/or you have been able to get to the market quicker with a product as a result of using and supporting, or gaining the support of, Eclipse?

Heintz: Absolutely. DSO, or Device Software Optimization, is something that not only Wind River, but most of the companies in the traditional embedded market, are now embracing. It takes a little bit of a different model and different look towards operating systems and development tools than a lot of our customers took in the past.

Before, operating systems and tool vendors all had their own proprietary ecosystems. So if you were going to build an iPod based on a specific ARM processor, you'd look to the market, and there was usually only one IDE that you had available to you as a choice and one operating system that was ported to that particular processor.

We got together with the other companies in our industry to say, “Let’s embrace Eclipse. Let’s embrace some more pluggable models.” You can choose the appropriate debugger technology on the backend.

In the device-software development world, there are a lot of different ways to debug an embedded system. You can connect to it with a hardware probe; you could attach to it over Ethernet; you could attach to it over USB. It's a very different debug model.

All the tools are very specialized, based on what you’re building. Time-to-market is something that is demanded by our customers, especially in the consumer-device market. They’re trying to release products on a six-month time window or less. So, they want to choose tools, they want to ramp up the speed, they want to plug into a common environment, and put their product out the door in a very quick period of time.

Gardner: One of the things that we’ve seen is this rapid ramp-up and, as Bill mentioned, a large market share. That’s very powerful. That brings a large community together. So, even with the technical benefits of Eclipse at hand and acknowledged, that community brings a marketplace to vendors like yourself. And that marketplace is, in fact, developers.

As we know from the history of IT, attracting developers is extremely important for a number of business-model reasons. Can you give us a sense from your business model what this community means, and what can you do moving forward to perhaps better take advantage of the community around Eclipse?

Heintz: Because we’re dealing with customers in the C and C++ world, we’re at an earlier stage in the Eclipse-adoption cycle than the Java developers. We’re trying to take an active role with Eclipse to help promote Eclipse as a platform for C and C++ developers. Bill talked about the 58% market share that he gets to enjoy on the Java side. We're in a much, much earlier stage on the C++ side. We see the benefits, but we’re really at the stage of helping promote that to ISVs, to some of the partners in the C/C++ ISV community right now.

Gardner: Okay, Bill, on this same notion of extending the benefits and leveraging the community, where would you like to see Eclipse go, and how as a vendor in the Java community would you like to steer this as a beneficial and productive community development process?

Roth: The development of the extension or the plug-in market would be one thing that would be valuable. We’ve actually benefited from some of the existing plug-ins. Our initial Spring support was from a great project, SpringIDE.org. Continued development and hopefully a business model behind it that let us offer plug-ins that offer more value to our customers from third parties would be excellent.

How we want the market to develop from a vendor perspective is that there are a number of important projects that are coming online right now that need to be adopted, and one of them, of course, is the Web Tools Project.

By the end of June, Web Tools Project Version 1.5 should be out, and this represents a major improvement in stability and functionality. The Web Tools Project and project model provide some fundamental technology for people that are doing Enterprise Java and server-side Java development. That model for building the applications is one of the things that’s our core focus -- making sure that that gets adopted.

Gardner: There’s another benefit from Eclipse here for those who are in a mergers-and-acquisitions mode. If you’re acquiring or being acquired and you’re Eclipse-based and the other company’s Eclipse-based, that offers some opportunity for getting to market more quickly and with less headaches in terms of integration. You’ve had an experience with this, Bill, at BEA. Can you give us the story?

Roth: We made the decision to take our current product line, which was called WebLogic Workshop, to Eclipse toward the end of 2004. It was important for us -- and it’s a substantial rewrite -- but we wanted to get into the Eclipse tooling market a lot faster.

The leading company of the independent Eclipse IDE vendors was a company out of Cupertino, [Calif.] called M7, started by some engineers from the former Symantec. For those in the Java community, you remember Symantec Visual Café. The chief architect and many of the engineers were from that particular project. They had a great product with some really interesting inspection software called AppXray, which really gave people the ability to see all of the aspects of a web application in one place.

It became clear to us toward the middle of 2005 that we needed to get into this market and get to market as soon as possible, because of all of the energy that was around open-source frameworks. We knew many of our customers were using open-source frameworks on WebLogic’s server. As a result, it became a natural acquisition. We bought M7.

We’ve integrated them, they’re now part of my group -- the Workshop group -- and their technology is really at the core of our offering. So right now, we’re in the process of taking our mainline technology, which will support folks from WebLogic Gate 1, and then merging it with the M7 line of code, which has been renamed BEA Workshop Studio, and we hope to produce a merged product by the end of the year.

Gardner: Steve, over at Wind River I know you can’t talk as a public company to a great extent about future plans around acquisitions. You’ve done several in the past few years. How does the Eclipse Foundation factor into a decision process around merger and acquisitions?

Heintz: Well, I can tell you that acquisitions are actually what originally drove our decision to adopt Eclipse. As you said, Wind River, acquired a number of companies over the last several years. And about three years ago, we had acquired, I think, four different companies that had their own proprietary IDEs.

Back in the old embedded approach to software development, everybody thought that their tool was the center of the universe, whether they were providing a simple editor or whether they were providing a test and diagnostic tool. We had these four IDEs that came into our product portfolio. We needed to decide which foundation we were going to use to build our single product line, and that’s when we took a look outside -- where Eclipse was at, where the Eclipse Foundation was at -- and decided to become a top-level contributor in the [Eclipse Device Software Development Platform Project] that we helped found.

This [DSDP Project] is helping move Eclipse to the C/C++ development world and helping move it to the specific needs of device software developers. Now, going forward, I can tell you that the first question that I ask of potential partners when we sit down at the table is “Is your product an Eclipse plug-in, or do you have a roadmap to take it to be an Eclipse plug-in?” because that substantially accelerates our ability to work together as a partner. So it’s absolutely one of the first requirements we look to for partners or further relationships.

Gardner: One of the questions I have been wrestling with on a philosophical level is the notion of whether Eclipse is an exception or whether Eclipse is a harbinger of what we can expect in terms of development, where a commonality or a federated mentality up to a certain point works very well. … What are your thoughts on this, Bill? Is Eclipse a model we should look at for the future in terms of a number of hybrids of development -- being open source and commercial? Or is this really just a one-hit wonder?

Roth: In some respects, Eclipse is unique; but in some respects, it gives us patterns that we can follow. I have a distributed team. I have engineers in San Jose, San Francisco, Seattle, Boulder, New Hampshire, Portland -- you know, they’re all over.

So that’s much like Eclipse. You got a bunch of people in Ottawa, and then you got people here, and then you got people all over the world. So, as a collaborative development model and a governance model it’s actually doing quite well, because, you know, [Bill] Joy’s Law: Most of the smart people don’t work for you. There’s Roth’s corollary to Joy’s Law, which is, most of the smart people don’t live in San Jose. I know that’s hard to believe.

Gardner: It is.

Roth: The fact of the matter is that this is the way that development really will be done in the future. That’s really one of the lessons that Eclipse has to offer. One of the interesting things is that IBM had sort of the germination of this project.

That is most significant -- and what’s going to allow for the building of a broader community -- the extensibility architecture and the fact that they chose things like [Open Services Gateway Initiative (OSGi)] to be the basis for this. It actually ties way, way back into some of the academic literature around System R and System R Star or the [IBM] Starburst Database Project to build an extensible database.

That’s sort of structured everything about how we view a base technology that can provide value, but yet still allow innovation, and a lot of innovation at that. In essence, it is somewhat unique, but we’re going to see more and more of the Eclipse model take hold across a number of projects that are going to be successful.

Gardner: Can you offer a couple of prophecies in terms of what types of projects, what types of technologies, you think would be ripe for this model next?

Roth: Well, that’s a really good question. There are a number of interesting things that are percolating. If you look at enterprise service bus [ESB] and some of the new category around service infrastructure, that sort of support, a SOA or a service network -- those types of things are where we’ll see the next model like this.

For example, in our service bus, we support not only mainframe connectivity, but Tuxedo connectivity, web-service connectivity, file connectivity, and all those things are plug-in-based and can be extended. Some of the high-order software, like service bus, are probably the next hit for this.

Gardner: How about on your side, Steve? Philosophically, do you agree that this is not a one-hit wonder, what the Eclipse Foundation has done, and if it is a pattern to be repeated, where would you like to see it head next?

Heintz: The way that the Eclipse Foundation is set up, the ability for member companies and contributing ISVs to influence the project on a regular basis, is very powerful.

From the Wind River perspective, Eclipse is not the only open-source project that we deal with. We actually sell a commercial Linux distribution as well to our customers. Our customers are putting Linux in routers or consumer devices, and I can tell you when I talk to my peers on the Linux management team or engineering team, on the Eclipse side of things, we really get to influence the project on a much more regular basis and get the extension points that we need in the software a lot more regularly.

So they really envy the model that is set up around Eclipse, as opposed to what they have to deal with influencing the Linux kernel or the Linux projects.

Going forward, Eclipse is going to be a great forum for some of the major challenges that face our industry and our customers in the future. We look at semiconductor companies coming out with most of their chips now being multi-core chips in the embedded market and the device market.

And, as Bill talked about there, new languages are being talked about, new methodologies for debugging and analysis and visualization of systems that run multiple cores, multiple processors, sometimes even multiple OSes in a single cell phone that you might get delivered in the future, or a digital TV, or a set-top box.

So these are some big programming challenges that our customers haven’t faced before, and we’re looking to some of our ISV partners, we’re looking to the academic community, we’re looking even to our own R&D teams to come up with new proposals and new ways to do this type of multi-core development, diagnostics, and debugging in the future.

Roth: Dana, Steve calls up one important thing, which is that … well, he’s got C++; I’ve got Java. We have a multi-language future in front of us. What we’ll see are developers building more and more technology in multiple languages.

There was recently a study by one of the market data firms that saw that, in general, Java developers -- my community -- use more languages when they develop than Microsoft developers. So, we’re heading into a phase where there’s multi-language development going on, and I can’t see how the people with proprietary IDE technology -- like Borland, like Oracle, for example -- are going to be able to adapt to that and have any real usability experience. Whereas companies like Wind River and ourselves are able to adapt -- because it’s fairly easy to mix the two languages. This is one of the untold stories.

Heintz: That’s a perfect example, Bill. When I take a look at some of our largest customers, customers in the telecommunication space that have thousands of developers, some of them are doing Java development, some of them are doing C/C++ development, some of them are doing mainframe development or scripting.

We went into one particular customer where they had 250 different development tools across a 5,000-developer organization -- nightmare to manage. These customers are making the decision on their own. They want to go to one common development framework.

Unfortunately -- well, fortunately for us – [Microsoft] Visual Studio is not an option. Microsoft is never going to support Linux development in Visual Studio, nor are they going to support Java development in Visual Studio very well. And so, these customers are choosing Eclipse as their base foundation.

Luckily, we were ahead of the curve. Now, we get the benefit from these customers coming to us and saying, “We only want to talk to you if you can plug into our standardized Eclipse Desktop that we’ve deployed to these software developers.”

Another great example is a very large military project, which is part of a future combat-systems initiative in the recent [U.S. Department of Defense] program by Boeing. They looked at all of the development tools available to them in the market, and they chose Eclipse -- specifically, they chose Wind River Workbench -- as their standardized development tool for all the subcontractors in the project, because everybody could write their plug-ins to a published, open set of APIs and standards.

Gardner: I think from the vantage point of 20/20 hindsight, one of the lessons to take away from Eclipse is it accelerated into the market rapidly, because it satisfied reduction of risk from both the user perspective, as well as the ISV and provider perspective.

And by that, I mean the contingency on a platform-level of risk for the user has been removed, or at least reduced, by the commonality of the Eclipse Foundation. The risk around tools and the choice of tools and the long-term implications of that has been reduced.

And whenever you get a situation where you’ve got a risk reduction, which means, you know, financial benefits on both ends of a virtuous cycle. It’s hard to beat. Do you agree with that, and do you think that’s what’s going to keep this spinning for some time?

Roth: Oh, most definitely.

Gardner: And you don’t see any real curtain-call on Eclipse. This was not a period for a consolidation -- and then we move on. This is something that’s got legs to it?

Roth: It’s partially because the notion of this history of extensibility. What that really means is a kind of scaffolding. If your question is, do things like the core Eclipse -- do they continue to develop and develop and develop -- I don’t know.

I think at some point in IDE, you get to the limits of what you’re able to provide, and the core of Eclipse architecture will be just fine. That’s a good thing. It forces the innovation for companies like Wind River and ourselves [at BEA] to basically innovate at higher levels and provide more and different value.

At some point, Eclipse may be just like oxygen. It may be part of the atmosphere; but it will be at the hub of everything we do for rich client tooling for software.

Gardner: Steve, the curtain call. Do you see a timeline on Eclipse, or how do you view this for the long term?

Heintz: For the foreseeable future. There are still some big challenges and big, big steps of innovation that are yet to be seen in our world, especially around C/C++; like I said, around multi-core programming and development, around multi-OS programming and multi-language development.

There’s going to be some time before we reach that point of Eclipse being the finished framework. And that’s fine. That’s exciting to us. We want to continue to contribute to that evolution and that change. But I don’t see this train stopping any time soon. Like I said, our major customers are deploying this across thousands and thousands of developers. Developers like it, our customers like it. It makes sense. It saves them time, money and increases their productivity. This is going to keep going.

Gardner: Great. Well, I think this has been a very educational and interesting discussion. I want to thank you both.

We’ve been discussing the impact of Eclipse among ISVs and in the market at large with representatives from two large software vendors. At BEA Systems, Bill Roth, vice president of the Workshop Business Unit, and also from Wind River Systems, Steve Heintz, director of product management for developer technologies there. Guys, thanks a lot for your time.

Heintz: Thank you, Dana.

Roth: Thank you!

Listen to the podcast here.

Transcript of Dana Gardner's BriefingsDirect podcast with product managers from BEA and Wind River on the ‘Eclipse Effect.’ Copyright Interarbor Solutions, LLC, 2006. All rights reserved.??

No comments:

Post a Comment