|Artist:||James Sugrue - Eike Stepper||Plays:||85|
|Length:||56:46 minutes (51.98 MB)||Downloads:||2336|
|Format:||MP3 Stereo 44kHz 128Kbps (CBR)||Download:||Click to download|
As part of the Galileo podcast series, I had a chat with Eike Stepper, lead of the CDO Model Repository project, with special guest Ed Merks - the lead of the Eclipse Modelling project. We discuss the impact that modelling has on software development, and discuss changes and the future of the Eclipse ecosystem.
James Sugrue: Could you introduce yourselves please. Eike, would you like to go first?
Eike Stepper: Yeah, let me introduce myself. I studied mathematics and computer science in Hanover in Germany. That's pretty long ago now. And pretty much at the same time, I had founded my first company, in Hanover, which was in consulting. And I still have this company these days. It's basically 18 years ago, and was able to conduct dozens of customer projects and gather a lot of interesting insights to a lot of companies. Well, that's mainly what I am today, I would say.
Sugrue: And your company is focussed on Eclipse stuff?
Stepper: Yeah, absolutely. It was not as it began, of course, but these days, I would say the last five or six years, it's focused on Eclipse technologies. It's particularly about OSGi and modeling technologies.
Sugrue: How about you Ed?
Ed Merks: Where does it start? I've been doing the EMF, the Eclipse Modeling Framework stuff, sort of a while back, when Eclipse was first starting in 2002. And really, the rest of the modeling project grew from that starting point, with GMF and various other things coming along. CDO has been around for quite a few years now. So yeah, it's very exciting for me to watch all these different components. I think of the modeling project as sort of a layered onion, and we just keep building more and more interesting layers, and the layers are building up more rapidly each year.
Sugrue: And Eike, You're mainly involved in the CDO project in Eclipse.
Stepper: Yes. I mean, it started from the beginning that I was deeply involved into EMF as well. Basically, I'm an EMF committer for nearly five years now. And, as I said, I'm the leader of the CDO Model Repository project, and lead of the Net4j Signaling Platform project as well, which is used by the CDO project. And recently, I was elected as an E4 committer as well, to have an eye on the modeled UI and modeled workbench efforts and the interoperability with model repositories and other model data sources.
Sugrue: Ed, are you involved in the CDO project as well as EMF?
Merks: I'm not a committer on the project, but I work closely with Eike. And it's obviously another layer in the onion, so we're doing a lot of talking about things that could be better done in the EMF core to enable CDO. So, certainly, I'm well aware of all the stuff that's going on and work very closely with Eike.
Sugrue: Great. And maybe one of you guys would like to explain what the CDO project actually is.
Stepper: Well, CDO is basically a three-tier architecture for distributed, shared models. So, it's sometimes perceived as a model repository only, but I would say its scope is somehow a bit broader. So, these days, I like to see it as the multi-tier runtime environment for models. And that includes, basically, three main parts.
One is the loading of models from a central model repository. And it's important to say that it's generally a lazy loading that takes place. And at the same time, CDO supports lazy unloading of single model elements.
So it is a mostly transparent effect that CDO brings to EMF models, but it's particularly important, I think. And this aspect of CDO, this scalability aspect, is certainly one of the aspects that led, well, let's say to the hype that CDO created over the last year.
The second part is, of course, the persistence. So the model repository, of course, is about model persistence. And CDO has a very flexible architecture to plug in different kinds of persistence layers at the very bottom of the technology stack.
The third point, I would say, is the distribution of model changes to all the other clients that are connected to the model repository.
Merks: And that aspect, you can almost think like the Google Wave stuff, if you've seen the Google Wave demos, how, instead of just emailing notes and having all these different broken threads, the clients are all looking at one shared model and are making changes to that model. And they're seeing immediately the changes that others are making to that same model. So the Google Wave stuff really made me think of that aspect of CDO.
Stepper: That's a good idea. That reminds me that one of my team members recently proposed that we could nicely integrate with the Wave protocol itself, to use it in the CDO project. I'm very curious to see where this could take us.
Sugrue:That sounds really interesting. I wasn't aware of that third part, of sharing the model across multiple clients, even though it's clear when I look at the architecture diagram. I was talking to Scott Lewis from the ECF project, and they've got their real-time shared editing. Do you think that CDO and ECF could do something together so that you'd be able to do shared editing on any type of model, rather than just document-based models?
Stepper: Well, let me say I'd love to work with Scott together. And actually, I did this already, in the area of the Net4j Signaling Platform, which is used by CDO, well, basically, as a network protocol layer. In this area, we have already integrations between ECF and Net4j, so it's basically possible to run the CDO protocol on top of the ECF framework as well. But with respect to the doc-share plug-ins of ECF, I'm not so sure if we are really addressing the same target audience. As far as I understand it, the ECF document sharing is more about distributing text document editing primitive operations or something like that.
I must admit, I'm not a real expert in this area. Well, I don't see too much overlap there, functional overlap. If somebody else does, I'm certainly willing to investigate that further and collaborate with whoever is willing to build interesting technology there. Ed, your opinion?
Merks: Yeah, I know you've been talking with Scott, and he's definitely interested in this type of cooperation. But everyone is stretched pretty thin these days in terms of real-time and commitments, right?
Sugrue: OK. So, the CDO project, has that been running very long?
Stepper: Well, actually, it has. So long that I had to clarify with Ed when it actually started. I couldn't remember exactly anymore. But it happened that CDO started outside of Eclipse, particularly at the SourceForge service, at the beginning of 2004. And in autumn of the same year, it migrated towards Eclipse and became, first, a component of the EMFT project, which is essentially the incubative project for EMF.
And while it incubated there for some time until it graduated, only last year, shortly before the release of Ganymede. So I would say it's essentially five or six years old now.
Sugrue: That's quite impressive. I wasn't too aware of it until, I think, at Eclipse Summit Europe, I heard some stuff about it. So that was my first exposure to the technology. And it targets a lot more than relational databases. I mean, that's what it took out of it, the persistence layer, as you mentioned. But you can use anything for persistence with CDO. Would that be right?
Stepper: Yes. Well, the persistence layer of the CDO technology stack is at the very bottom, of course, where we have the model repository server. And this layer is divided into two further layers. The upper one is a more general layer, focused on things like session management, notification management, lock management, stuff like that, which is itself not dependent on a concrete back-end type.
And the lower level of the repository server is concerned about the integration with existing data back-end types. And in this layer, well, it's, of course, completely pluggable.
So, in general, you could plug in any data source which is able to provide something that can be turned into models, let it be relational tables or let it be object databases themselves, which is, of course, a very obvious integration because there's no mapping, so it's usually faster and more scalable, even on the server side.
But you could even imagine to plug in file-system stores. Or it should even be possible to integrate with text-versioning systems like CVS or Subversion or whatever, on the server side.
Sugrue: And are all EMF models ready to use with CDO? So, if I've got my EMF model, can I use CDO straight away?
Stepper: Well, I've thought a bit about this question because, I mean, an EMF model has, usually, two sides of the coin. At the beginning, it is an Ecore file. It is really just one file that contains a model, maybe several files. And we call these dynamic models. And all these dynamic models can be used directly with CDO. So you don't have to deploy them, for example, to the server separately. They're handled by CDO like normal objects, and you can just commit these models into the repository server at runtime.
So, in this regard, I would say CDO can be used with all EMF models. But on the other hand, usually, when you talk about EMF models, you're talking about generated EMF models. And then it's a bit different, because models that are normally generated cannot be used directly with CDO.
The reason is mostly that I told you about the scalability effects that CDO has on EMF models, so that single objects can be unloaded at any time and the garbage collector can really purge them from memory.
This is certainly not possible with models that are normally generated, because then you have strong Java references between all these model nodes, which just keep the objects in memory, even if they are not used directly by an application.
So, to gain these additional scalability effects for your EMF models, you are normally required to regenerate them with one or two changes in the generator model. And after that, well, then your models are perfectly usable with CDO as well, and have all these additional benefits, of course.
Sugrue: And do you just use the standard EMF tooling for adding these extra attributes?
Stepper: Yeah. There are only two generator model properties that have to be changed. You can either do this by hand. It's really easy. But we have, also, a migrator tool, which changes these plus another three convenient properties automatically for you. Just right-click on your existing generator model, start the CDO migrator tool, and everything's done automatically. I would like to point out that the Ecore files, or the core models, don't have to be changed just to be usable with CDO.
Sugrue: So it's just the generated code.
Stepper: Yeah, exactly. In other words, CDO is completely un-invasive to the core models of EMF.
Sugrue: Another question I'd have, then, is if I've got models that I haven't used EMF for (now, who'd imagine such a thing) Could CDO work with those models?
Stepper: Well, basically, I can't imagine what sort of models should that be.
Merks: I mean, one might argue that such a model you could treat as a persistence layer at the bottom tier, and then you're communicating with that layer and still surfacing it as an EMF model. But definitely, you need to work with an EMF model for CDO to function properly.
Stepper: From a CDO perspective, well, I would say it's a bit hypothetical, but CDO has a very clear, layered architecture, and it's basically possible to exchange each of these layers. It could, for example, be imaginable to use a CDO repository and the CDO network protocol but a different client-side integration. So, to integrate with another sort of modeling framework. But I can't imagine that anybody's tried to do it so far. And as I said, I would even not know exactly what kind of modeling framework that should be at the moment.
Sugrue: So, if I think I need to use CDO for my project, I suppose, actually, the first question I should ask is: what would be the typical type of application that needs to use CDO, or that would benefit from using CDO?
Stepper: Well, in general, I would say applications that already use EMF for modeling their data structures, their data needs, they usually use file persistence, XML persistence. They store their model instances in files. And then, at some point in time, they reach some limits of this approach. And these limits could be of certain natures. For example, let me mention again the scalability things. The more and more modeling becomes popular and is used in companies, the larger usually these models grow.
Well, this has some limits if they are to be stored in XML files, because XML files can only be read in one chunk, so completely or not, and with pure EMF usually if they are loaded once, it's comparingly hard to get rid of them from memory.
So the scalability parts of CDO are these days a huge driver of the desire to use CDO, because we have evidence, for example, of models of far more than four gigabyte size that can be, for example, transformed by tools or operated on by applications. That's usually something which causes a headache for those who try it with EMF alone. Ed, I think you agree with me at this point.
Merks: Yes, definitely.
Stepper: Persistence, of course, I said it, persistence itself, so multi-user access to models with transactionality and object-grained locking of model elements is also something that EMF alone does not bring to the users, and with CDO you have all of these, like we call it orthogonal aspects and functionality in a coherent framework and a coherent technology stack.
Sugrue: So it sounds like if I want to add this cycle of scalability and multi-user aspects to my application, and I'm already using EMF as my modeling, then CDO would make a lot of sense for those things?
Sugrue: OK. And adding it to my existing project, it's just a matter really of having EMF in there and adding in the dependency to CDO plug in and adding in these generator properties, would that be correct?
Stepper: Basically, yes. Well, usually I summarize it as a three-step introduction process. So you have, of course, to set up a server, a repository server, which is really simple. There are different ways. I don't think that the technical details are so interesting here. From what I know, most of our users manage within five or ten minutes to set up the first CDO repository server. So that's the first step.
As I said before, it's completely generic, so at this point in time, you don't need to think about what models to use with the server. So it's really a generic server. The models will be committed later by the applications.
The second step is certainly the preparation of the used models, the EMF models, which usually involves regeneration, as we talked about it before.
The third, and usually the last, step, is that the existing applications have to be prepared to use CDO, so to create or to open a connection to the repository server, and to associate this connection with an EMF resource that they are using anyway.
So there is always a bit of scaffolding in such applications. Usually, the resource set has to be prepared in some way to get access to the model resources. And in this case, they are no longer an XML file, they are on the remote server and that's usually another five minutes change.
And after that, your applications are usually properly connected to a CDO repository and profit from all these orthogonal functionality that is added into them.
Sugrue:It sounds very good. It sounds like within a day, maybe, you could have all the benefits that CDO gives you added into your project, maybe at a simpler level.
Stepper: Sure, yeah. I have evidence of that, and some customers invite me to help them in this process of migrating their applications from file-based normal EMF applications to distributed CDO based applications. Last autumn, I had evidence of a project where the customer hoped to learn about this within one week, and we actually did it within one day. So it's really not that complicated.
Sugrue: And if I've got GMF used in my project as well, is that OK?
Stepper: Well, I must admit I'm not an expert in these things, the CDO committer team has grown in the lifetime of CDO to eight commiters at the moment, and we have one and a half persons or commiters which are particularly responsible for all the UI integration stuff, and GMF is a big topic there. I know that it's possible already, so from our CDO side, we met some design preparations that made comparing it easy to integrate with GMF editors - not to ask you about the details right now, but this is surely a very interesting integration and we will focus on that after Galileo as well, of course.
Sugrue: OK. At the user interface level, apart from the possibilities for the GMF editors, does CDO help anywhere there, or is it more that CDO is for the modeling and back-end side of things?
Stepper: Mostly, indeed. But we have some reusable UI components. We have, for example, some eclipse views which enable it to interactively open and manage sessions from a client IDE, or an RCP application as well, towards a CDO repository, to start transactions from there, to commit the transactions or roll them back. We have a very new view, which we call a watch list, where you can register particular objects and see the change history of these objects. And you see at once if some other user in the network changes properties of these objects, so this is a bit like the change history and in the CVS plug in.
And of course, we have a special editor, a generic editor which enables to open resources from a CDO model repository, edit the objects inside, and see all of the changes of other users immediately, and stuff like that.
So it was initially intended this as a sort of generic user interface for developers to play with the objects in the repository, and stuff like that, but we paid attention that these components are reusable, extendable, and you can use them in your own project as well and build on top of those.
Sugrue: And you mentioned earlier that you've gone and you've helped some customers, so it does seem that CDO suits enterprise level applications a lot, do you have a lot of commercial users of CDO?
Stepper: Yes, of course, of course. Personally, I have the feeling that the community divides into two groups. One is, of course, the group of researchers, universities and research organizations. Some of them even tried, several of them indeed, maybe, tried to come up with similar technology. So modeling is gaining a lot of momentum in general, and research organizations realize that and try to come up with model repositories for this purpose.
I know of two of these efforts who are currently trying to use CDO even in their efforts of coming up with some modeling repository infrastructure. But I would say the bigger group, the really bigger group, is the great number of companies that use CDO as a runtime technology in their applications and their application systems.
For example, one of the very, very early adopters was the U.S. company Echostar who operates several orbital satellites, and they manage their whole asset management from their satellites down to the smallest cable in their receiver stations in a CDO model repository.
Then NASA, for example, a very famous commercial customer, is using CDO for the next NASA mission to do the mission planning and mission control for the next Mars explorer mission.
The Canadian Space Agency uses CDO to - that's also interesting, I think they are using it to let a number of distributed robots operate on a distributed shared model, which reflects the sensor measurements so that they can all operate on them, in a controlled way.
I know it's only because they very early sent a full-time committer to the CDO project. What they are using it for is so secure - am I saying that right?
Merks: Yeah, secure, secret, classified.
Stepper: It's classified, I have no idea what they are using it for. But they are doing it for several years in production now. They, for example, contribute a very interesting back-end integration with objectivity data bases, which was obviously for them the only one fast enough to fulfill their distribution needs.
Sugrue: I guess it makes sense that they've got a contributor into the project because of means sake, and help influence the way the project goes to suit their needs, even if you don't know what their needs exactly are.
Stepper: Exactly, exactly. They are, for some reason, pretty much interested in performance and scalability and they have introduced a whole lot of features to improve these characteristics and it's amazing to see how we can cooperate. It's really nice cooperation.
Sugrue: And it's very interesting as well that all of the examples of the CDO users that you've mentioned are in the United States and in Canada, rather than in Europe, where Europe has traditionally been the center of modeling.
Stepper: Yeah, we have evidence of a lot of commercials users in Europe. I, in particular, have a lot of customers in Europe that use CDO these days. Bombardier for example, well it's a Canadian enterprise, but I was busy with the Bombardier folks in Sweden to migrate a tool that is used for planning railway stations in general, which was already built on EMF and had to be migrated to a multi-user application system.
I'm in very tight contact with several Swiss banks - that's interesting because these are some of the first customers or users that use CDO not so much as a runtime technology, but they have a strong interest in using a CDO together with other open source modeling technologies as a development tool or technology.
They are finally interested in storing their development models in a CDO model repository. So we have a lot of evidence of commercial use bases in Europe as well.
Sugrue: That's good. Ed, your talk must be working on The Unbearable Stupidity of Modelling. It must be having an effect on people.
Merks: I keep trying to convince people how stupid it is, and it's just not working.
Sugrue: So what are the plans for the next year of development in CDO?
Stepper: Well, we have a whole lot of feature requests pending that we were not able to address in the Galileo release cycle. I picked out four of the most interesting ones. At the very top is what we call an offline mode. By the way, I did not explain what the abbreviation CDO is for. CDO is for connected data objects. So the original idea was that each single object of a model stays connected with a central copy of that model, where it was fetched from.
So in all these years, CDO did not come up yet with an offline mode, a disconnected mode. So, for example, if the network connectivity gets lost, even if it's for a short period, than usually the CDO session to the repository is terminated and, in the worst case, even all of the dirty local work is lost and must be redone.
In this regard, it's really similar to a JDBC connection. So if you lose the JDBC connection to a database, there is usually no technological means to bridge such periods.
This is what most users requested from CDO. We even started a bit on this effort, because it's basically made of two separate problems. One is identifying the parts of the repository you want to check out to have it local and be able to work on it when the network goes down.
And the other part is when the network comes back, to resynchronize your local work with the newer repository state.
And the second part is already realized, so I think that very shortly after the Galileo release, we will be able to come up with a proper offline mode for CDO. That opens really new possibilities and use cases for CDO. Another point is we just added a query framework for remote queries.
It's basically a generic transport framework for queries and query results on the way back.What we don't have so far is what we call a common query language. So you remember I told you that we have different sorts of back-ends, and we even don't know all the back-ends that exist for CDO at the moment. So what we really want to have is a common query language that can be sent to the server no matter what particular back-end is connected to the repository.
While OCL is one possibility we talked about, there are several companies very interested in this sort of functionality, SAP, for example. They have a lot of experience in this area, and we really hope that they join the team in the next year to participate with us on this effort.
The third thing that is interesting, I think, is branching. I think we didn't talk about this so far. CDOs, for example, able to transparently version your models in the repository server.
So this is an optional feature; you can usually switch it on or off, but when it's on, then changes to the existing model don't override the old state. Internally, all of the old states are kept, and the clients are able to switch back their view of the model to see consistent historical views of the whole model.
This should be extended in the next year to even have parallel versions of the model. So just in a similar way as we know it from CVS, Subversion, ClearCase, or whatever, I think that's an interesting point.
And the last of the top level points is that, especially together with that, we have to support what we call legacy models, in a better way.
I told you that EMF models have to be regenerated to be compatible with CDO, and while when that's possible at all, it's usually the better way, but sometimes that's not possible. Maybe you don't have the generator model, you don't have the original Java sources of the generated model, or whatever. In all these cases, we would like to support these sorts of models as well, and call them from CDO point of view Legacy models.
Sugrue: That sounds like you've got a lot coming out for the next year. You're going to be busy.
Stepper: Yeah, boredom is not very probable.
Sugrue: And then, while you're there, in the overall modeling project and in EMF in general, especially, I suppose, is there anything big coming up first in the Galileo release, and then is there anything we can expect in the year?
Merks: There's quite a bit of interesting stuff happening in Galileo. I think the Xtext project is particularly exciting and new, and it sort of parallels what we're seeing happening at Microsoft with their Oslo, M efforts. I think a lot of people are recognizing the value of textual DSLs, and it's great to see Eclipse advancing to pick that up. I think CDO itself is an amazing piece of technology. Eike has more committers on the CDO project than our committers on the EMF core project, so that's a significant achievement. It's growing very rapidly. I'm getting jealous. I'm going to have to raid some of his committers soon, I think.
I think it's also very interesting, the Teneo integration with Eclipse links, so that we have - it works very well with Hibernate already, but being LGPL, that's problematic for some consumers, and having integration with the Eclipse link is a great story for Eclipse and for CDO itself, because it can piggyback off of that type of support.
So I think there's plenty of exciting stuff happening in the Galileo release. The Compare project is graduating as Teneo, and CDO did last year, so the maturity of the EMF projects components is improving.
I think for the next release you only have to look at the project proposals page over the last six months and see that - I don't think it's an exaggeration, I'll have to look at the numbers, but I think on the order of half the new projects that have been proposed in the last six months are within the modeling domain, so things are not discontinuing to grow, but growing more rapidly.
Sugrue: And EMF Core itself is probably quite mature and stable at this state.
Merks: Yeah, certainly, if you look at the newsgroups or mailing lists, there are discussions about should there be an EMF 3.0, but to me, it's extremely important that the established user base gets stability, and don't pay any costs for new features. We want to be able to innovate and do exciting new things as well, and some of the things Eike talked about, like transactionality and better support for CDO are important features for the future, and I'd definitely like to see changes in the Core to better support things like CDO.
So definitely I expect to see some innovation, but there are a very small number of active committers on the Core, and a huge number of people are depending on it. So only so much can get done, and definitely we have to be very careful how it's done.
Stepper: It's interesting, the three particular components you mentioned, Ed, Xtext, EclipseLink, and EMF Compare, they are particularly interesting from a CDO perspective as well, because we plan to use Xtext for the implementation of the common query language for CDO, which I've talked about. Sometime ago, I started discussions with the EclipseLink team and Doug Clark in particular, they are pretty much interested in cooperation with CDO. CDO, of course, is also interested in that, to attract more back-ends and back-end users.
I think, from an EclipseLink point of view, if I remember correctly, the versioning and auditing, the temporality, functionality of CDO is pretty interesting. With respect to EMF Compare, we plan to use it in CDO as a sort of last resort conflict resolver in local transactions - that are the three points I'd like to mention.
Sugrue: Both of you, as very active committers and members of the Eclipse community, you've got your finger on the pulse with the Eclipse ecosystem. Have you noticed any big differences within the past year in the Eclipse community?
Stepper: Well, I think it's obvious that, for some reason, the number of the big members of the Eclipse foundation got reduced a bit, and on the other hand, smaller companies gained a bit more momentum, I think particularly here in Europe and Germany; Ed, I think that's your observation as well?
Merks: Definitely. I'm on the Eclipse board, and you can see the character of the membership of the board changing, and you can see the revenue base for the foundation is changing. It's not entirely clear how much is a reflection of the economy and how much are long-term systemic changes. Yeah, there's definitely a change in this regard. I think the committer base is still continuing to grow, and a lot of people have very personal excitements invested in this stuff, and we definitely see, like I said earlier, the growth of the modeling project continues to accelerate. So I think things will change in a good way, I believe.
Stepper: The modeling itself is becoming more and more important. I think in Europe, this is known for a longer time already. I heard that in the Northern American countries, it has not been perceived in a really similar way, but I have a feeling it starts there as well, and it just becomes obvious that modeling is an important part of these days development processes as well as a runtime of applications, of users and customers applications. No?
Merks: Yeah, I think so.
Sugrue: And I think there is nowhere more obvious of how far modeling has come than E4 with its modeled workbench, which is modeled on EMF -that's fantastic and it makes sense.
Stepper: Absolutely. As I said at the very beginning, that's the reason why I became an E4 commiter now, to take care that all these efforts, in one sense, go in the right direction. There are very competent people already on board, but particularly that it will nicely cooperate not only with XML files -but even with CDO for example, or Teneo itself as a client-side, object relational mapping for these models.
And if you follow this idea a bit, there are pretty amazing things imaginable that you can do with that, just think about your whole workbench structure is modeled with EMF and lazily loaded from a CDO model repository and all the changes that are committed to this repository are reflected immediately in all these connective clients.
So I think this is not interesting for each and every user of this, but I guess for a real number of them, it can open whole new worlds of use cases. All of it's pretty interesting.
Sugrue: Ed, do you have time to work on the e4 project at all at the moment?
Merks: Not nearly as much as I would like, no. But it's fun to monitor the activities, and there's a big base of people growing indefinitely, so once this Galileo train is out of the way, I expect I'll have more time to focus. Anything people need, I help them do. It's just mostly I play an auxiliary role rather than direct development.
Sugrue: Ed, what are your thoughts on the future of Eclipse, where it's going and where it will go?
Merks: It's funny you ask, I'm just writing a blog. A blog about exactly this type of topic. I think the industry is changing dramatically. I don't think anybody knows where things will end up. But there's something broken, there's something that has died, and we don't know what will replace it. I think the term "freetard, " I've really gotten to like the term "freetard, " and I think the world has really gotten to be a little bit freetarded. They just think everything is free, "Look, we've got this free stuff from Eclipse."
And some people seem to think that they just need to whine and snivel and complain, and that somehow more free goodness will flow to them just by virtue of them doing that, but in fact this stuff isn't really free. I think Bjorn has blogged about that a lot.
It takes time and effort to install things; it takes time and effort to learn stuff. And yet many companies, they want it to be so free, they don't really want to pay anybody anything to set it up or to educate them. It's just kind of crazy.
And people like Eike, they work independently, and they need to pay the bills, and the money - it's an investment to put effort into Eclipse, and people need a return on investment.
I have no idea what the future will hold in terms of return on investment, but at some point, all this free goodness can't just simply be free, there needs to be a return on investment for the people who invest in it.
How that will come about? I do not know. Usually people learn from painful lessons. Painful lessons are good educators. Until people feel some pain from all this freeness that they're getting, they'll probably just completely take it for granted.
What that pain point will be, I don't know, the lack of someone cutting off their free flow, or them needing something badly and it not getting done despite crying. I'm not sure what will be the pain point.
Sugrue: It is encouraging, though, just over the past few days, the increase in the people who've become friends of Eclipse. I know it's only a small nominal donation, but I guess it makes a bit of a difference.
Merks: Yeah, I got a note saying I'm a friend, so I get a download of Galileo early for being a friend. So that's cool. Of course I have a backdoor access.
Sugrue: I think it's a good benefit. Things like that are good, and I think it's good the amount of consultancies, people like Itemis and EclipseSource, and all these different companies that are able to contribute to their projects, but still get some revenue by helping out customers who really need to use those projects. It's probably the same with CDO and EMF.
Merks: Yeah, I think that's really the way of the future that there are just certain issues that people have with buying products. You buy a product from somebody, and they control all of the source, they decide when a new version of the product comes out and what you have to pay for it. They decide when they do a big technological shift and you get a different product than the one you had before.
Just look at Microsoft as a case-in-point. Did we really need Vista? Did we really need PowerPoint and Word to look completely different than what we were familiar with? That's just forced on us, right? And you're a huge company, and somebody tells you, "Sorry, you need to re-architect your entire process because we're going to change our product architecture." That's a big scary thing.
So it's control of the technology and control over the costs. It's a lot cheaper to spend a bit of money on learning and educating and acquiring skills than to keep forking out money for products year in year out and being at the product vendor's mercy.
Stepper: I can only agree. EMF and CDO, as well as many of the other projects at Eclipse are real good examples of great innovation and part of this innovation is rated in terms of money that had to be spent to develop a comparable technology. Some of these projects like EMF and CDO, they would cost millions of U.S. dollars to develop them for companies themselves, and all this innovation surely has to be funded in some way.
I think the future of Eclipse is tightly bound to the question: How will this work out in the future? Will it be possible to fund it? Will enough member companies be there to assign their developers?
On the other hand, we have a lot of projects which are not funded or driven by a single member company, like CDO for example, CDO has never been driven by a single company, so funding of all this innovation is tightly bound to the future of Eclipse itself, I would say.
Sugrue: OK, great. I'm really, really impressed by CDO. I came into this broadcast by having only read a little bit about CDO and knowing the bare minimum about it, and now I really, really want to use it in my product, and I really want to see how this GMF part goes for getting to the graphical stage. So, really, it's a fantastic project, and best of luck with it and with the rest of the modeling project.