There's an English saying, "
A penny saved is a penny earned". The bean counters of the world who run companies large and small follow this religiously. Carefully managed accounting books tally every bean; the more beans left over on the bottom line, the better the result. That bottom line is the difference between the earnings and the costs and because accountants have little control over earnings, costs are the variable they carefully scrutinize and minimize. Of course earnings don't come without costs, so it's not merely a matter of minimizing costs but rather a matter of optimizing costs. Therein lies the fundamental flaw with the old saying. It may well be the case that a penny saved is a penny twice lost.
Consider the money spent on marketing. It's clear that such money must be spent: without such investment, earnings will drop due to reduced market demand. So how much should be spent on marketing? That's a tough question; intelligent people are likely to differ in their opinion though it's clear that making as much market impact as possible for as little money as possible is optimal. It's always the case that making a good impression requires investment.
In the
topsy-turvy world of open source software, where money is spent on software that's given way for free, the bean counting formulas go into a tailspin. At best the open source effort can be saved by resorting to a marketing slant, that is, if we give this software away for free, we will grow the market and will increase demand, or save costs, for whatever we're producing for this market. This is what justifies spending billions on Linux (spare the expensive Window's license associated with each computer sold) and hundreds of millions on Eclipse (ensure that the Java platform is competitive with the .NET platform).
I used to work for one of the largest organizations of the world, so I have a good understanding of the corporate mindset. One of my final lessons learned there is that managers really don't like it when you send notes to their managers: sending a well-intended, constructive note about how best to optimize open-source investment, i.e., essentially the content of the
blog I wrote at the start of 2008, proved the old adage "
No good deed goes unpunished". So now I work closely with
itemis, essentially doing the same thing as I did before, i.e., ensuring that Eclipse modeling technologies thrive in a growing market. To digress for a moment, for me personally, the most exciting software technology this world has to offer in this space is
Xtext, driven by the experts at itemis. I fundamentally believe that the integration of concise notations with well-established software platforms, is the optimal way to improve on a good thing.
Xtend is a great example of what I mean, i.e., it's simply a better Java that integrates seamlessly with Java, i.e., it's evolution rather than revolution, improving on what exists rather than replacing it. My own work on
Xcore emulates that same approach. Please come to the
Eclipse Demo Camp in Bonn for a closer look.
In any case, back to the issue at hand: optimizing a company's bottom line beans. The problem in this regard at itemis is no different than anywhere else. Fortunately itemis has an enlightened view, recognizing that the cost of open source investment pays off in the end. One way that's the case is the money spent on services and that's why assembling the world's leading modeling experts into a cohesive organization has been one of their goals. A battle ground faced by all service companies is that other organizations often see a penny spent on services as a penny best saved; the cost of those savings are all too easily overlooked.
Consider an example back in my earlier days. EMF is used by a lucrative web server platform as part of their start-up configuration model. EMF was one of their 's favorite scapegoats: EMF slowed down start-up performance with its bloated byte code. Of course when you have a bloated model, there's only so much you can do, but that argument goes nowhere fast. Therefore, when I caught wind of this complaint, I pointed out that they could generate much less byte code by changing package creation to load each package from its serialized form and by using dynamic feature delegation for the implementation classes. Sure, both of these generate slower code, but the important point is they generate less byte code, all of which needs to be loaded at startup, and then bloats the process when it's no longer needed after start-up. They changed these two options in the generator model, regenerated the code, and presto, sever start-up improved by more than 40% with less than a day of effort. Previous efforts to improve start-up involved man-decades of investment, yes decades. In this case, my help didn't cost them a penny. Unfortunately neither the savings nor the improved sales were ever calculated, but I did get a huge thank you for my invaluable help. Okay, that last part is just wishful thinking, I never got so much as a kind word. Oh well, it's good to help prevent fires.
In any case, my message to the enlightened developers of the world is to manage their bean counters more effectively. Don't let them rule your organization. When you need expert help, demand that you get it. Spend that extra penny and earn that extra dollar. A team of unproductive developers producing inferior quality results is a cost that must be brought into focus. Demand that this be measured and that it be factored into the bean formulas. The team of experienced exerts at itemis, including me, are always available for personalized help. We do workshops too, like
the one I'm doing after the Bonn Demp Camp. The Eclipse community as a whole is rife with expertise so for goodness sake, spend a penny, with the realization that in addition to your internal savings, much of that penny will go back into the development of the next generation of the free software that you know and love. It's an investment in the future, an investment in the commons, and an investment in a better way to build the word's software foundations.
Unfortunately, learning Eclipse's Git tools has been a bit of a nightmare. Its poor support for proper line feed handling continues to be frustrating. I compare learning Git to being given an advanced new hammer, one without a handle, that if you just instruct it nicely to do what you want, will do the job ten times better than ever before. Only the instructional language is Gitinese. It's very hard to pronounce, with lots of German "ch"s (think hissing snake), "st"s, and "sp"s (think "sht" and "shp" where the "h" is implied), plenty of Dutch "g"s (think clearing your throat), and no end of "th"s (think "s" but with your tongue hanging way too far out; it is a very unusual sound if English is not your native language). Anyway, enough bashing Gitinese and the Germanic languages. Once you learn them, they all sound as if they were simply meant to be that way. Oh well, back to Xcore.
Of course we needed a logo, so I whipped one up. Maybe someone will contribute a nicer one. On a more substantial front, with the help of Dennis Hübner, we have our first builds of Xcore available. It's been contributed to the Juno repository. (Note that he's working on making EMF and XSD 2.8 build with Eclipse 3.5 so that we'll have more permissive version ranges that are properly tested.) I also finally found time to write a wiki tutorial for how to get started with Xcore. Lots of cool things are working rather nicely. We even have support for organizing imports. So have a look if you have the time.
Posts
