Skip navigation
2006

Tom Baeyens's Blog

November 2006 Previous month Next month

 

I'm pretty fed up with the latest attempts of Intalio to get a free misleading ride on the open source wave. I can deal with competition based on features, even if we should lose. I can stand open source competition. But i can't stand that the open source is abused in the way they do.

 

Their latest press release called 'Intalio Donates BPMN Modeler to Eclipse Foundation' was the drop that made me cool my frustration in this blog. Currently there is only the model... and a screenshot. I wonder how long it will take them before the TODO's are done and the community will see a usable 'BPMN modeler' as they refer to it in their communication. What currently is out there doesn't even come close. Of course, they are free to choose which parts they open source and which not. I acknowledge that. But if you want to be recognized as an open source company, you got to take a different attitude. E.g. other people can use all of jBPM's technology IN FULL. With jBPM, you can even extend it, redistribute and make your money without paying us a penny.

 

But before this press release, I was already fed up with their cheap insinuations of being open source. For one the title of their home page says: 'Leader in Open Source BPMS'. So I checked it out and tried to download their product. This is a snippet from the license i had to click through:

(c) Restrictions. Unless otherwise agreed in writing by the Parties, Developer shall not (and shall not allow any third party to):
  • (i) copy the Intalio Software or any portion thereof,
  • (ii) use the Intalio Software in live production or with live data except on allowed databases or application server,
  • (iii) decompile, disassemble, or otherwise reverse engineer or attempt to reconstruct or discover any source code or underlying ideas or algorithms of the Intalio Software by any means whatsoever,
  • (iv) remove any product identification, copyright or other notice,
  • (v) provide, lease or lend the Intalio Software to any third party or use the Intalio Software for timesharing or service bureau purposes,
  • (vi) modify or create a derivative work of any part of the Intalio Software,
  • (vii) load or use any portion of the Intalio Software at any site or on any equipment other than that indicated above, or
  • (viii) disclose any performance information or analysis to any third party (including, without limitation, benchmarks or evaluation test results) from any source relating to the Intalio Software.

 

IANAL, but my guess would be that neither OSI nor FSF would consider this an open source license :-) So I made a wise U-turn when I saw this license.

 

I hear their defense coming: "Oh, but we didn't say that our core product was open source, we said that critical components are based on open source and we contribute to open source."

 

There are many companies contributing to and using open products... and that is just great! And we welcome all Intalio's contributions to open source in that perspective. But if your product contains the above restrictions, and if you only open source minimal parts of your 'critical components', i don't think you are entitled to describe your company as 'The Open Source BPMS Company'. For more insinuations of linking the brand of open source to their brand name, see this google search.

 

So my advice to Intalio is 'Get honest'. Either commit to open source or stop the insinuations that you are open source.

 

Before you get the wrong impression, I'm absolutely not religious about open source licenses. This is a completely different matter. I'm just against a misleading marketing.

 

Different from Intalio, recently a whole tsunami of companies have committed to open source. In most cases this is because they've been put against the wall by open source competition. These companies get my respect, but they have a hard time monetizing their open source software. Let me tell you with my limited business skills: IT IS NOT EASY. Building a scalable business on top of open source software is not easy.

 

IMO, JBoss and Red Hat are still very much underestimated for their pioneering work in building businesses on open source. I repeat: IT IS NOT EASY. Building communities. Developing and finetuning a completely new business model. Working with just a few of the best developers out there. Getting the right partnerships in place. Leveraging the efforts of the community. Respect that other people want to make money too. Internal development culture. And this is just the tip of the iceberg of all things that need to be just right in order to build a business on open source. For me personally, putting the very top notch developers to work closely in a very small team is the most awsome part. I often refer to it as 'an explosion of creativity'.

 

My response to those that are still in the phase of "you're not open source because you're making money" is the following: My project (JBoss jBPM) is now alive and doing very well only because JBoss helped me in bulding a business around it. So everyone can now download, use and redistrubute my entire team's work for free. This would never have been possible without the JBoss open source business model.

 

Another response is that it's middleware... Who the hell would develop professional, scalable, usable, production-ready middleware in his spare time ? Right: no-one! What DOES happen is that peole have great ideas that they want to work out. That might spark an open source project. Working out your own ideas and the community feedback can keep these enthousiasts motivated for some time. But sooner or later, there is always the moment where it gets harder to combine a day time job with your open source hobby. That is where people that don't make a living out of it give up.

 

I was reluctant for quite a while to express my respect for they pioneering work that JBoss has done in the field of open source middleware. Mainly because I'm an insider or... "contaminated" as some have called it :-) It's a relief that I finally came around to publish my testimonial and frustrations around bad marketing. I feel a lot better now :-) And I hope that it can inspire more people will to realize that building business on open source is not easy and give due credit to the pioneers.

 

The link between models and code is overdue on a serious revision. Hard core developers usually hate point-and-click IDE's. Managers make models that are not in sync with the software. The current perception that software artifacts is generated from models is seriously flawed.

 

This is my conclusion after several years of building the JBoss jBPM process engine, which targets business users *and* developers.

 

After messing with assembler, programming languages grew higher and higher level. Then UML went mainstream. In that context it was assumed that developing software would be done with models in a short future. This is the typical MDA vision.

 

Higher level abstract models improve communication with business users. But there is the tradeoff between flexibility and complexity. To be executable, software needs to be specified precise and with lots of details. Putting all these details in the model, makes the modelling language too complex for its purpose.

 

Models should be projections of software artifacts. This should replace the idea that software artifacts should be generated from models.

 

The argumention goes like this: First, we recognize that there are different types of authors involved in creating software: business users and developers. Business users can think along on the model level, but they don't know about the technical details. Developers are the power users. They can write the actual software artifacts and communicate through the models with the business users.

 

Also developers should be differentiated: Currently, developers are real powerusers. They type in straight Java code way faster then any point-and-click IDE could enable them. But i think that a whole bunch of less experiences technical people are impatiently waiting until they can use languages (or subsets of languages) that are less complex. They are willing to trade flexibility for simplicity.

 

If models are a projection of actual software artifacts, there is no need for the models to contain all the details. A very good example of this notion is the method implementation in UML class diagrams. In UML class diagrams, method implementations not available, which is good because that makes it possible to get the overview. The collapsable compartiments in class boxes are another illustration that sometimes you don't want to show all the details in your models.

 

Before 'markerless round trip engineering', we have been able to experience that keeping models and code in sync is not possible for the majority of software teams. So in this context, it also makes good sense to distill the models from the actual software artifacts. That way, they can't get out of sync. I'm not even close to a UML tooling connoisseur, but the best approach I have seen in UML class diagrams was the old Together IDE. In that tool, the models were generated from the code. The diagram file only contained the graphical information which was not part of the Java code.

 

So in my refined model software is composed of many software artifacts in various general purpose programming languages and a bunch of domain specific languages (DSLs). The value of models is that many of these deployable software artifacts --that contain great detail-- can be projected, resulting in a visual diagram that shows the higher level concepts without the details.

 

a very enlightning picture :-)

 

In the picture above, i have represented the actual software artifacts in the middle. These software artifacts are written in a general purpose programming language or a domain specific language. DSL artifacts are usually input for runtime frameworks. But the main point is that the software artifact layer contains all the details necessary that define an exect behaviour of a runtime environment.

 

Some (not all) of the software artifacts can be reprensented in models. These models can be generated from the actual software artifacts. Business processes are a great example of this.

 

So my conclusion is that models should be projections of software artifacts. Wether people use the model-editor or the text editor to author these artifacts doesn't matter. Of course, business users will more often use the model editors and developers (the power users) will use the text editors more often.

 

Another aspect that is highlighted here is that software is being build as a mixture of general purpose programming (e.g. Java) and a bunch of DSL's which serve as input for frameworks. So the thing that currently is mostly overlooked is refactoring over these language boundaries. The future IDE should be able to detect and execute refactorings over language barriers. That is when we'll get really agile development teams.

 

Note on relativity: I know I may sound like I just had a great innovative insight. It sure feels that way :-) But most probably, as with many things in life, this will be invented, described and analysed many times before in many different contexts... If that should be the case, I thing it was definitely worth bringing it again to your attention :-)

 

Regards,
Tom Baeyens
Founder and Lead of JBoss jBPM

Filter Blog

By date: