Creating Children You Didn't Know Existed

To numb the impact of Jeff's departure, I buried myself in work today. I've been mulling over a hard problem that's seems to have come up rather frequently of late. Given that it's also one of our few plan items, it seemed like high time to tackle it. Suppose you have a nice simple model of a file system where you have an abstract base class, Resource, that has a name attribute, and two concrete derived classes, File and Folder, where Folder contains an unbounded number of resources as follows:


Notice that the two properties "Child Creation Extenders" and "Extensible Provider Factory" are new; Dave's still needs to review the changes so goodness knows the names might change before this is committed. Notice too that I've set the "Extensible Provider Factory" property to true in anticipation of making the editing support for this model extensible.

When I generate the usual EMF edit support, I end up with the following editor, where I can create files and folders in a hierarchical structure and give them names.


Now suppose someone else came along and wanted to add support for symbolic links to this model. They could do it with a new model that extends the resource model as follows:


Notice that I'm setting the "Child Creation Extenders" properties to true, since I'll want to be able to create links in the base editor for the resource model.

With another click of the mouse, the code is generated and I can bring up the same editor as before, but now the menu is extended to include the ability to create links:


And of course we can edit links to make them reference other resources:


So there you have it. The item providers for a base model can make themselves extensible and then the item providers for a derived model can generate extensions for the base model, thereby integrating themselves with the editor for an unmodified base model. Extension points are the most wonderful thing!

Well, my office is starting to feel like a prison.

It's time to put an end to this week.

All Aboard!

The deadline for submitting contribution questionnaires for any third party packages that you would like to include in Ganymede is fast approaching! January 31st will be here and gone before you know it. Don't miss the boat, because it's leaving without you!



Err, I mean all aboard! The train is leaving the station!


All these metaphors are so confusing...

Would You Like Fries with That Sir?

Have you ever been to the golden arches and been asked if you'd like fries with your meal? It's considered good service to anticipate your customer's needs. You'll note though that they don't generally ask if you'll be needing ketchup with those fries you just ordered. That's because the ketchup is free and it will serve them well if you forget to ask for it. Now I suppose some will argue that nothing is free and that even if you don't get the ketchup you'll have paid for it anyway, but I digress as I am so often inclined to do...

The essential point here is how best to offer good service to your customers. Of course customer is a misnomer for the folks who consume our relatively inexpensive software at no up front cost. I like the term client because there isn't an associated connotation of money changing hands. One of the best ways to provide good service for your clients is to be helpful and answer their questions. The newsgroup is the front line for this service. At Eclipse it is a resource that is well exploited by the clients. Unfortunately, the service providers are often overwhelmed by the volume and are in short supply. I'm not suggesting that everyone needs to service their newsgroups with my fanatic zeal, but all too many newsgroups are sadly lacking in responsiveness, and that kind of saddens me.


Mostly I only answer newsgroup questions but on some rare occasions I do feel the need to ask a question. That was the case on Sunday. Two days later the question languishes and I feel neglected. Of course I take everything very personally, so I feel as if my question was somehow not worthy of an answer. I suppose it wouldn't have been so bad if no other questions were answered, but other questions that came after mine were answered. I feel like those other people jumped the queue. I hate it when people don't wait their turn!

I wanted to remind others in the community hoping to make their projects successful that I believe EMF's success and the growth of the modeling community has been helped to a great extent by paying very close attention to the newsgroup. That's where I find out what problems people are having with EMF and what kinds of problems they are trying to solve using EMF. It's a valuable source of information and is the best way to keep your finger on the pulse. I also get personal satisfaction out of knowing that I've helped someone by saving them time. I often spend large portions of my day doing nothing but helping others on many of Eclipse's newsgroups. And as you might imagine, newsgroups are not the only source of the needy; the company for which I work is very large.


So let me climb up on my high horse for just a moment, before you knock me down. I believe strongly that helping others is its own reward and that it's best not to expect anything beyond the satisfaction of having helped. Granted it's nice to get a little bit of positive feedback, and one of the best is that you will eventually notice that setting a good example encourages others to follow. Try not to be disheartened when you occasionally go looking for help only to find it's in short supply. Treat all your clients like they are valuable because your projects have no meaning without them.

EMF and RAP Go Great Together Too!

I finally managed to get our infamous RCP Library application RAPified and running with the RAPified EMF UI libraries. The results are in 213988. Here it is running in a browser.


The most challenging part of the whole exercise for me was getting the darned thing to launch. It's tricky because you need to include plugins that are not actually required based strictly on plugin dependencies. Getting the magic URL right is important too.

I ran into a few issues, one of which is already fixed (those RAP guys are quick!) with a simple patch; it sure is nice to have the RAP source code extracted from CVS for easy hackability. There was also a problem with activation that I've asked about on the RAP newsgroup, but I managed to hack the Shell implementation to make that work too. The viewer pane rendering is still kind of screwed up and it is rather dysfunctional too; it should look just like the pane title on the properties view, but I'll get to that eventually.

So now we have EMF for RAP, eRCP, and GWT. Unfortunately I never have been able to figure out how to get GWT to work for me, but Tom has made good progress on that via 209434, 209435, and 211340.

I'm having one of those "get a life dude" moments, but soon February 2nd will roll around and then I'll be boarding this ship for a week:


After that, I transfer to this slightly fancier beauty for another week. Great flag eh?!


The past week had it's fair share of controversy with the communal desire for an image editor running counter to the platform's desire for minimalism; I hope the discussion doesn't degrade too badly. I'm waiting for another chapter of "as the stomach turns" on this one. And of course there was the very interesting spin off bugzilla to move JDT and PDE out of the platform. "Just say no to special status" I fired off provocatively. Aren't diverse communities great? Never a dull moment or a lack of opinions, that's for sure! I'm keeping a close eye on these...

EMF and eRCP: Two Great Things That Go Great Together

The Eclipse Modeling Project and eRCP are both Jolt finalists. Gorkem blogged about it already. He also blogged about the last MIDP specification ever and about the latest eRCP release. So this, along with Ralph's request for some background information on the modeling project's relevance to the embedded community got me thinking about how beautiful the Isle of Saints will be in February.


Just kidding, it got me thinking about how EMF is a lot like chocolate: it's goes well with so many things and is kind of addictive once you get started. So in true manic developer style, I left all the other half completed important things on the back burner, and decided to dive into eEMF, an eRCP-enabled version of EMF, much like the RAP enabled version that's partially done. Or maybe it's completely done; I still have to test it now that Rüdiger Herrmann helped me figure out how to launch the darned thing. It's the little things that cause me the biggest problems...


First I tried to extract all the eRCP source code from CVS. I have this compulsive need for being able to butcher other people's code. There's kind of a hodge podge in that DSDP repository, but it didn't take me long to guess that I wanted all the stuff under org.eclipse.ercp. So I extracted it but the result was kind of a build disaster. I have no idea how this stuff is supposed to be set up and built. Projects would be a lot more open and would get better patches if it was easier for folks to set up the project's source code. For EMF we have a detailed wiki document for this, including the instructions for the elaborate contortions we must go through to work around 109137 so that we can bootstrap our development environment. That's right, we eat our own dog food in the modeling project, so we ensure that's it's fine cuisine that's far too good for dogs.

So I gave up on on the CVS extraction and decided to grab the shiny new 1.1.1 download and use that instead. Unfortunately that immediately left me thinking, hey dudes, where the heck is the SDK? It's open source and I want the darned source because even if I can't butcher the code I really do want to see it! Oh well, enough griping. Things really improved after this. Fortunately I already had a CDC 1.1 JRE set up, using the handy dandy wiki for that, from a previous attempt to convince myself that EMF 2.2 really does work with Foundation 1.1, which I always thought was extremely cool given that it wasn't even a goal.


In less than three hours I was able to get a functional application working! Most of the changes were to delete the code that depends on the optional org.eclipse.core.resources plugin. I had to delete large swaths of org.eclipse.emf.edit.ui, since lots of things in eRCP's UI apparently aren't supported. After making the compiler happy, I made sure that the org.eclipse.emf.ecore.xmi plugin was still working when using the microXML implementation in eRCP; indeed it worked like charm. Finally I needed to build a little GUI application, so I snarfed eERPC's eWorkbench example and turned it into a com.example.library.ercp.eworkbench example. It displays a little tree view of the Library model as well as a copy of the Ecore model of itself.

I'm very impressed. This eRCP stuff was really easy to set up and use. I put all the results in 215378. I suppose this means we really ought to produce a build for EMF 2.2.1000. Won't Nick be pleased! I'll wait to get some feedback to see how much interest there is in this.


I even tried to get the XSD model working, but the ability to serialize a DOM seems to be absent and the level of DOM that's provided doesn't support events. So I disabled these aspects to enable a read-only version of XSD, which would still be useful to support EMF's ability to read an XML instance with a schema location for which the XML Schema to Ecore mapping is used dynamically. So I tried to get that working, but to my horror I ran into what looks like that darned Crimson DOM problem from the old Sun JDK that just never got fixed. This time I could provide a patch and we have the code in our Eclipse CVS so I'm much more hopeful to get it fixed.

So ends another compulsive day. Thank goodness that vacation is looming on the horizon...

Modeling Associations With Ecore

It's often been said that Ecore doesn't support associations. Although, like EMOF, it supports bidirectional references, it doesn't support the full generality of CMOFs notion of an association. An association in the general case consists of two or more features and those features can either be owned by the association or by the classes being associated. So while a simple association, where the ends are not owned by the association, is quite effectively modeled as a pair of references that are related as opposites, the full generality of an association is not directly supported by Ecore. But that doesn't mean they can't be modeled!

Let's start with a simple example to show how we can model associations, i.e., how we can map the CMOF concept of an association onto an EMOF realization using only classes. In all these examples we will be be associating an "A" and a "B" where each "A" is related via feature "bs" to at least 2 "Bs" and at most 4 "Bs" and each "B" is related via feature "as" to at least 3 "As" and at most 5 "As". I use the multiplicities so I can demonstrate how these multiplicity constraints propagate to the different parts of the realization in the screen captured tree views below.

In the simplest case these would just be a bidirectional references as are directly supported already, but suppose we want to carry some data on the link that associates the instances. We could model that like this:

So the idea is we model the association instance as "ABLink" and include with it the "data" which in this case is just a string. We arbitrarily pick "A" as the container for the link, and hence the "a" feature of "ABLink" is just the bidirectional opposite of "As" "aBLinks" feature. Then "B" also has a reference to the link via its own "aBLinks" feature and in this case too, the "b" feature of "ABLink" is the bidirectional opposite. Both "As" "bs" feature and "Bs" "as" feature are derived from their "aBLinks" feature by viewing the corresponding "b" or the "a" feature of each link. Populating a link involves adding the link to the link-holding features at each end. Note that I'll need to investigate how to describe the derived features' derivation declaratively so that it can be emulated in a dynamic model and generated in a static model, but you can imagine that declaring "bs" is derived via "aBLinks/b" would be pretty clear and simple.

Suppose we wanted to deal with the case that one of the two ends of the association was owned by the association instead; this is the approach you'd take if you could not modify "B" to add an "as" feature. We could do something like this:

In other words, we simply don't have the features in "B" and instead the "b" feature of "ABLink" will be the only way that A and B instances are associated. Note however that the multiplicity constraints for "B" have disappeared! This approach works well only if the "bs" feature that we've omitted has lower bound 0 and upper bounded unbounded, and even then, it's hard to find all the links involving any particular "B" starting with a "B" instance. Populating a link for this design involves adding it to the link-holding feature of "A and setting the "b" feature explicitly.

Here's a different approach that doesn't lose the multiplicity:

Here we've introduced "ABAssociation" as a container for managing all the link instances. It has a map that uses "BAMapEntry" to map the "key" which is of type "B" to the "ABLink" instances that involve B. Note that the "value" feature of the map entry captures the multiplicity that each "B" must have at least 3 "As" and at most 5 "As" though expressed in terms of the links. Note too that the "ABLink" has an "bAMapEntry" feature which is the bidirectional opposite of the "value" feature of "BAMapEntry" and now the "b" feature of the "ABLink" is derived again. So this approach enforces all the constraints. Also, we would provide convenience operations to get the "as" for a given "B", to get the link if it exists for a given "A"and "B", to create or update the link between a given "A" and "B", and finally to delete the link between a given "A" and "B". Populating a link directly involves adding the link to the link-holding feature of "A" as well as to the link holding feature of the "BAMapEntry".

Now for the most complex case, the holy grail of associations. In this case, neither "A" nor "B" can be modified as part of describing their association. Here's the approach:

Now the "ABAssociation" has two maps one from "A" to "B" and the other from "B" to "A" though expressed in terms of the links. We choose one arbitrarily to contain the links so the "value" feature of "ABMapEntry" is a containment and the "abMapEntry" feature of the link is its bidirectional opposite. The "bAMap" is just like in the previous case. Now both the "a" and the "b" feature of the link are derived from corresponding feature in their containing/referencing map entry. We provide the same convenience methods as the previous case, including an additional one to get the "bs" for a given "A". Populating a link directly involves adding the link to both maps. Note that the multiplicities are preserved in the two "value" features.

Voila! Who says Ecore doesn't support associations?

If you're interested, you can track the progress of 105920. It contains a zip of the complete model as well as the generated code for it. Note that the use of colors and fonts in the tree views reflects progress on 95934, that the multiplicities on operations and parameters is a work in progress, i.e., I drew my own icons pending good ones from the graphic designers, and that the ability to show "2..4" and "3..5" is a hack to make the screen captures more illustrative of the solution. Comments and feedback would be most welcome!

One a personal note, my vacation plans have been postponed for a week because the ship is in dry dock for longer than expected, so I'll have to wait for the first two weeks of February for my current mania to come to an end. And finally, what blog of mine would be complete without a gratuitous photo of something cool? I hate to disappointed people! I took this cool picture on a previous trip to the Caribbean where even the fungus are fabulously fascinating:

The Life of an Eclipse Board Member

I seem to have woken up obscenely early yet again and that so shortly after my "pretend vacation" came to an end on Monday. Fortunately I have a real vacation coming up at the end of the month. My pretend vacation provided the ability to work on whatever I felt like doing, so I worked on a whole whack of bugzillas; check out the release notes when we publish an EMF build later today with two dozen bugzillas completed. And that doesn't count prototype work to further ensure that pretty XML doesn't produce ugly models; the idea here is that often XML can contain levels of element nesting that aren't actually useful in the model itself. It's working, but it's still a mess. I wonder when I will find the time? Stop writing huge blogs you say? How rude is that? Be careful, or I'll have to give you one of my patented looks:


Another nice thing I did was to improve the performance of the code that builds state machines for XML Schema content models, i.e., bugzilla 200848. It's sad how slow instanceof and casting really are in Java. I think most folks have little idea how slow these are given how innocent they look and how prevalent they are. It's also sad how inconsistently a VM can behave in terms of JIT optimizing the byte code. It's like a moving target! And with so many JVMs as targets, it's compounded even worse. But enough whining. The reason I bring this bugzilla up in particular is to point out to all you helpful Eclipse people out there that it literally pays to remind your clients that Eclipse accepts donations. For example, the folks needing the performance boost for the state machine code were ever so grateful and as a result, their CTO, Paul Warren, donated $250. Similarly Christian Meier appreciated all the help I give folks like Philipp Kutter when they have EMF issues that need to be resolved. And of course, going down the list, David Lynch's donation of $500 was a good one! So don't be shy with your reminders!!


Now that I've lulled you with positive thoughts and shown you some mysterious photos, let me slip in here a comment about the "silence of the lambs" since it relates directly to the blog's title topic. For goodness sake, the committer community needs to be more active in expressing its views! We committers and the rest of the community have great influence and don't exploit that nearly enough. Look at all the excellent things Bjorn is doing in response to the feedback he gets; there's a man who really listens. Please nominate candidates for the community awards! The top contributor award is back because of our community's influence. And although I'm ever so grateful to be nominated as top ambassador, I'd very much prefer not to be the only nominee. I wonder if there is a rule against the same person winning the same award two years in a row? Chris would be stiff competition. He's always an inspiration to me! So I hope there is a rule, like a presidential term limit, that bans him from running because how does one compete with this?


As Mike blogged yesterday, it's Eclipse Foundation Election 2008 time. I wonder if anyone will nominate me this year? I sure enjoyed the experience of being a board member. It would be awfully nice if the committers could field more candidates than there are seats. Last year there were five candidates and it turned out that there ended up being five seats. What's an election without losers? It hardly seems like democracy! This year there are only four seats, but you can tell from Mike's hinting that he must have some strategic membership deals he's working on and an increase in membership could result in five committer representative seats yet again. I encourage others to run. If you want to find out more, I'd be happy to chat with would-be candidates individually. Let's make a big splash!


Given that I'd like to be reelected, I was going to look at my position statement from last year's election but it seems to have disappeared. How convenient is that? I can say without fear of contradiction that I did everything I promised and then some! Actually, I'm not sure about that. The board doesn't really work quite the way I expected, though mostly that means it works better than I expected. One of the things I found interesting is that the committer representatives are the folks most likely to come to the meeting with a specific agenda. We have a personal and direct vested interest in helping the foundation to better address committers needs. Nevertheless, effecting change is difficult even with lots of nice people.

One of the issues I tried to help tackle was the issue of how committed are the strategic developers to Eclipse and, mostly importantly, are they in fact living up to the obligations of their signed agreements? So Nick helped me to create what someone (who shall remain nameless, board confidentiality being what it is) affectionately referred to as the deadbeat list; and when I say Nick helped I mean, he did all the work and I took all credit. Of course the link for 2007 is much better populated with data. I thought of it more of a "who's doing what list" but then, as I was told at the board meeting, I have so much charisma; you know, such a statement has so much more weight when the speaker doesn't snicker while saying it and others don't laugh out loud as a result! I was almost completely frosted:


In any case, be very patient when you click on the links. It's best to open them in a new tab or new page and go there later; hopefully this isn't like inviting a denial of service attack! Actually, I think the query results are cached. Please read the disclaimer on the page very carefully as well.

We've asked Mike to vamp up the directors page with some pictures of faces and biographies so folks feel less like Eclipse is being run as star chamber. Hint hint Mike! See how easy it is to influence others? I was told recently as well that I'm such a subtle person; again, the snickering I could have done without. Here's a frozen twig in lieu of an olive branch for Mike:


Rest assured that the committer representatives are working tirelessly in what we believe are the best interests of the Eclipse community as a whole and for the committers specifically. Note that I qualified it because, as I stated earlier, the community has been stunningly less that vocal about raising issues for us to address, so we are mostly driven by personal passions. For example, we'd really like to see the parallel IP process extended to all projects as soon as possible, but that's taken far longer than we might have hoped. In terms of shorter term results, we've worked closely with Janet and her team to help streamline the IP process with improvements like completion date estimates; Janet's and her team definitely deserve recognition for the improvements they have enacted.

In my opinion, we need to review many of the rules that regulate the board's processes to help modernize them and make them more sensible and relevant for today's Eclipse. I.e., we need to be doing much like what Bjorn is doing with all the rest of the Eclipse processes. For example, the board agenda technically must be be circulated 30 days in advance of the meeting, but for short months, the meetings might be as little as 28 days apart; there's something not quite right about that, clearly! I think the board is often shy to deal with contentious topics; it typically prefers to act only when there is consensus, which is sort of a good thing and sort of incapacitating when there are several dozen board members, i.e., as many as there are geese in this out-of-formation flock:


I think there are many important things the board needs to do in the coming year and I'd certainly like to be a participant in helping the foundation build its momentum. I hope I will have the excellent opportunity and the great honor to serve the community for another year. I'll make sure Eclipse isn't going to the dogs!


Of at least if it does, that the dogs will be cute, loved, and well fed.

Manufacturing Profitable Cars with Free Materials, Parts, and Tools

New Year is always a good time for reflection, both for looking back on the past and for looking forward into the future. The first day of this year brings yet another snow storm to Toronto and I'm sure I have many more weeks of that yet to come. Fortunately, due to excellent planning and foresight, I have a sunny vacation planned in the Caribbean later this month. Imagine all the pictures I'll take!

Last week we had a weather condition I'd never heard of before: freezing fog. The results were very pretty and I was able to capture an additional two mega pixels of it with my new slightly improved camera; at 4000 by 3000 pixels there's plenty of room to crop! Of course I trim the images down when I upload them, so you'll have to take my word for it. Isn't it interesting how the growth patterns of the freezing fog so closely mirrors that of the Nootka itself? Nature loves reuse!


Looking back on the previous year, I'm happy that we made Java 5.0 happen for EMF 2.3 and I'm thrilled that the EMFT project has been growing exponentially. I'm also very pleased with the growth of the modeling project as a whole and expect this rapid growth to continue well into the future. I firmly believe that model driven development is the only promising mechanism by which the nature of software development will take a significant leap beyond its current limitations. I'm looking forward to what promises to be the best EclipseCon yet, and of course I'm anxious to get out the second edition of the EMF book really soon; it's already available as a roughcut on Safari.


In the bigger picture, I see the software industry continue to be in a malaise that stretches back all too many years now. Ask yourself this, is any major corporation seeing significant gains based primarily on software revenue growth? In fact, how many are valued higher now than in 2000? All too few seems to be the general answer.

The dot-com bubble was a reality check that continues to haunt us today. Irrational promises and market hype are no longer trusted, nor should they be trusted. I often wonder why anyone buys into any of the all-too-pretty stories the software industry loves to dish out. Mostly our industry generates new "solutions" like the old ones are going out of style and as a direct result continues to provide far too little in the way of lasting value. What exactly does service oriented architecture mean concretely? The use of modular units that can be assembled into solutions? Is that really different from what we were doing in the past?


Even many of the youngest among us will remember that Java started as a web-based user interface technology. Though it failed there, it evolved beyond that. Yet today we are led to believe we're back at that same point but that this time it will be different! Likely it will, but it also makes it glaringly clear why those spending money on software ought to be skeptical. What do you say to someone who asks, why should I spend money now on technology that's likely to be obsolete by the time I've trained all my staff and spent a fortune? But honestly, this time it will be different! Surely it wont be different given that all past and current evidence is to the contrary...

So now we have all this talk about governance. What a pretty word! If we just had good governance we'd be able to spend money on software more judiciously. Yet it seems to me we're operating in an industry that defies logic and common sense. For example, it's been suggested that EMF doesn't generate any revenue. Oh really? Those hundreds (thousands?) of products that use EMF make no money at all? Well, yes of course they do, but that's not EMF's revenue is it?

Let's draw an analogy, as implied by the post's title, to a more traditional industry, car manufacturing. It certainly seems reasonable to draw analogies between a software package and a car, both of which are intended to entice a consumer to part with their hard earned cash. To build a car, raw materials must be wrenched from the earth, refined into things like steel, glass, plastic, rubber, and so on. These refined materials are then assembled into useful parts which are in turn assembled into ever more complex units until finally they comprise a fully assembled vehicle. Every step of the process involves costs in terms of energy, labor, tools, and materials.


Software is not so different except that the raw materials are pulled from thin air and hence are difficult to valuate. The hardware needed to wrench software from the ether, i.e., a computer, is generally getting cheaper and cheaper to the point where it's vanishingly cheap relative to the cost of the overall development process, which not surprisingly is dominated by the labor cost. The development tools themselves, with the advent of open source, are now effectively free and not only that, but equivalent of the car parts are also freely available in open source. And worse still, even entire solutions are free. So we have free raw materials, free refined materials, free parts, free tools, and even some free cars. How does anyone profit in such a seemingly insane ecosystem? Well, you need to be very creative if you expect to make money by selling software and you'd better be prepared to move on when your software is commoditized. And it will be! It's likely best to try to make money in some way other than directly from the sale of the software.

When everything but the final result is seen as simply free, we really end up seeing some dysfunctional distortions that can only be corrected when there is pain, like the dot-com bubble burst, to correct the perception and the behavior. Just as a free engine doesn't spring into existence so that others can build more profitable cars, free software doesn't simply spring into existence either. Someone is paying a cost and bearing that burden so that others can use it. Of course some of the analogies break down because software can simply be copied; you just have to build one really good engine and then copy it for free. But nevertheless, you have to build the one really good engine and the cost of doing so is highly significant.

What's broken in our industry as a whole is a mechanism by which the costs of "free" things is shared among all those who benefit. When something like EMF is viewed by most everyone as something free to be freely exploited, then the folks who view it as an expense, will see it as primarily an expense to be minimized. And when there is no obvious measurable relationship between the investment and the return on that investment, the investment will continue to dry up.


The lack of a sound economic formula for measuring all aspects of a component's value and for sharing costs of ongoing development, service, and support of them, threatens open source organizations like Eclipse on a large scale; the platform is not different in kind from a tiny component like EMF. Within large organizations, the same types of funding issues arise. Clearly reusable components are a mainstay for developing the ever more complex solutions that are needed today, yet it can often seem more justifiable to fund many teams to solve the same problem in parallel than to fund a reusable component which "generates no revenue." Yet clearly duplicating effort on a massive scale makes no business sense, but issues of control and sharing of costs run counter to what's best in the big scale.

Today's funding formulae are broken and I expect that only pain will effect the changes necessary to correct the imbalance. It's just not a problem until it hurts...