Posts Tagged ‘open source’


Why wrong licenses kill good products

Being on the ODBMS train of thought, I checked out a few products that are out there, and something struck me – all of them would be really difficult to bring in to a project. The reason is not technical, but rather one of hassle. All of the products are either proprietary closed-source or GPL dual-licensed. These licensing models actively discourage people from bringing them into the enterprise.

Commercial software is notoriously hard to get approved, and there is generally a long-winded process that has to be followed so that the bean-counters can say “can’t you use an open-source alternative”. GPL dual-licensed stuff is almost as bad! Most of the places I have worked have a blanket ban on GPL software (excluding GNU-type tools which generally sneak under the radar in a server installation). Financial companies in particular are almost paranoid about this. Anything that’s not Apache, or LGPL has to go to the legal department, who will take ages only to eventually say “we’re not comfortable with this”.

Licensing is one of the main reasons I conciously jumped ship from the Microsoft world to Java. I found it really painful to get the most basic library approved for use. Who cares that tool X it would save me a week of development – it cost $50! Then I jumped into Java and it was like a blessing. You need a rules engine? Workflow? Plugins for XML for your IDE? No approval process – no worries! My life became much, much easier. I could just dowload what I required and get on with doing what I needed to do.

There are always exceptions. MySQL springs to mind. The fact that it is standalone made people a bit more comfortable using it without the specter of viral licensing rearing its ugly head. ODBMSes are not like a normal database. They integrate directly into your code and distribution to your server means that they are a core part of your application. I suspect that GPL may be triggered at this point because of the “distribution clause”. I have read the exact opposite on the DB4O forums, which say that server stuff is OK to use under GPL, but distibuting client (desktop) software that uses the ODBMS forces GPL on your application.

Hmm. This is a pretty murky line, and one that I’m not comfortable with. What about if you “distribute” your server software around a cluster? I’ll be happy to put my hands up and just throw this in the “too hard” basket. If I can’t advocate that a piece of software has no legal repercussions on the ultra-proprietary system that I’m writing, I will lose no sleep whatsoever looking somewhere else. I suspect that I’m not the only one. It seems that there is a fine line between external dependency and a core library that is part of the application.

I appreciate why dual-licensing is there, and acknowedge that it’s a valid business model – for certain types of applications. However, you just can’t see it working everywhere. How far would Spring have gone if it was GPL dual-licensed? You only have to look at ExtJS to see how well-received frameworks or libraries are when it becomes too hard to justify their use.

Most large organizations in my experience are more than happy to buy support for LGPL stuff. Once it’s in there, someone wants the reassurance that there will be someone there to bug in case of difficult issues or simply to point the finger at (depending on the company culture). Dual-licensed stuff won’t even get it’s foot in the door – not even a sniff at success. I would really like to use an OO DB in a real-world setting, but it just seems like it would be far easier to get around the hassle of getting it approved if I just used something that’s not quite a 100% fit for the use case. That’s a real shame, and the software engineer in me just sighs deflatedly as the realist wins again in the face of pending deadlines.

Maybe that’s why so many people put up with the object-relational mismatch instead of trying a different approach. In the world I live in, an administrator’s “no” outweighs a technical “yes” every time.

This post is not intended to create FUD, just to outline why uncertainty may be enough to stop someone working with what may otherwise be brilliant stuff.

Tags: , ,
Posted on December 7th, 2008 in open source, technology | No Comments »

Home Cooked vs Open Source. Or, Don’t Build Your Own Workflow.

First thing’s first. I love open source. I think that it’s the best thing since sliced bread. That thing that we were always told about since computer science, that of the open marketplace for components to be shared and reused HAS happened. Just not in the “buy this billing component” kind of way. It’s even better! It’s free (ish)! You download what you want and plug it in to your application. The quality varies, but if you keep your ear to the ground and do your homework, it will save you a lot of time. And time is money.

But just how much money?

I recently discovered Ohloh . It’s like professional networking, but not exactly, and it’s for open source. It has some cool features, but the one that got me instantly was that it trawls through open source repositories and gives you some very cool stats. Like just how much effort it would take to build an equivalent version of something, and how much it would cost given a yearly salary for a programmer. It uses lines of code, which are not a good metric, but rather an OK litmus test.

Another one of my favourite sites is Java-Source.net. Pick a particular category of software that you need, and it lists you a suite of open source options in Java – ready for you to do with as you will.

So let’s pick a category. Here’s one that I prepared earlier – workflow engines. Pretty much every place that I have ever worked has rolled their own in this regard. For some reason it’s considered a low hanging fruit (even though people write postgraduate theses on them). In some cases, off the shelf offerings are seen as overkill, too restrictive or just too complex. Most of the time the analysis is little more than gut feel, a kind of “Hmm… looks too hard, must have been over-engineered.” So a couple of guys get together and do a “bake at home” version. Pretty soon, the reality takes over and it doesn’t do what it’s supposed to, the use case was misunderstood, you need a management console, version control of process flows, different flows in different environments… uh oh! Suddenly, you spend a lot of time maintaining this beast.

So let’s do the stats and take the first handful of products listed on both sites (there are many others). These vary in the amount of activity going on, have quite varied features and uses – some plug in to applications, others are standalone orchestration engines. It’s not exactly scientific, but it’s interesting for illustration purposes. Let’s take the average programmer salary as $55000 (dollars, euro, pounds – it’s all about the sameish worldwide, so doesn’t really matter):

LOC = Lines Of Code

  1. Apache ODE. 108,547 LOC, 55 Person Years, $1,498,221.
  2. Taverna. 134,334 LOC, 33 Person Years, $1,832,157.
  3. jBPM. 286,618 LOC, 74 Person Years, $4,081,422.
  4. Enhydra Shark. 255,101 LOC, 65 Person Years, $3,576,525.
  5. OpenSymphony OSWorkflow. 48,303 LOC, 11 Person Years, $627,203.
  6. ObjectWeb Bonita. 67,916 LOC, 16 Person Years, $894,118.
  7. OpenWFE. 187,176 LOC, 47 Person Years, $2,608,592.
  8. WfMOpen, 152,557 LOC, 38 Person Years, $2,084,413.

The average cost of building a workflow engine?

155,069 LOC. 42 Person Years, $2,150,333.

Once again, this is completely unscientific. I have no idea whether the cost is over the lifetime of the product or initial development cost, whether management costs are included, we aren’t comparing apples with apples, and these are general purpose engines rather than a thing that does only the thing you want. But it does make for a very interesting question. Have you got the time and money to do this, or would you rather get on with the business problem at hand?

Enterprise software is a complex business. There are no shortcuts. There are no easy decisions. The landscape changes all the time. You have to weigh up support costs, training, extensibility, maintenance and skills.

My take on it? Someone did the heavy lifting already. Do yourself a favour and take advantage of it. If it doesn’t do exactly what you want, then the code is right there to change. You can always contribute it back, and if it’s good enough then it becomes the property of the community. The numbers are compelling.

Tags: , ,
Posted on January 21st, 2008 in architecture, java, open source, software engineering | No Comments »