Demand OpenID

From Prabath: Demand OpenID!

Open Source?

I'm very confused. I was listening to Dave Rosenberg on "why Apache License is bad for Open Source business", and I heard Dave say (talking about the add-ons that you get with Mule EE):

"Ours are not proprietary - ours are just not available in the community version. They are Open Source code: When you pay, and everything, or you become a subscriber, or whatever else, we don't actually keep anything closed." [About 6:30 into the podcast]

So the Mule EE extensions are "Open Source"?

Of course I'm not a paying Mule customer, so I don't get the special "paid for" Open Source, so its hard to evaluate. I can't actually find the Mule EE license agreement on the website, but there is an evaluation license agreement that makes interesting reading.

I think we - especially founders of Open Source companies - have a pretty clear idea of what Open Source is. If you don't, then take a read of the definition. A few really minor points spring to mind:

• The license shall not require a royalty or other fee for such sale. This sentence from the Open Source definition seems to blow the whole "paid for Open Source" concept out of the water.
  
• The license must not restrict anyone from making use of the program in a specific field of endeavor. I haven't seen the license that paying customers get, but the evaluation license says: "you shall not ... publicly disseminate performance information or analysis (including, without limitation, benchmarks) from any source relating to the Software. " Seems like a pretty solid field of endevour restriction.
  
• The program must include source code, and must allow distribution in source code as well as compiled form. Guess what the evaluation license says: "You shall not... (c) modify, decompile, disassemble or otherwise reverse engineer the Software or attempt to reconstruct or discover any source code". [My bolding] Oh. So its open source, but I'm not allowed to look at the code? That's cool. I like that. I used to do Philosophy... it reminds me of that.
  

I hope the Mule customers are less confused about how Mule EE is Open Source than I am!

P.S. If anyone has the Mule Master Subscription Agreement, I'd love to see a copy.

REST Anti-Patterns

Stefan talks about REST Anti-Patterns.

Simple scenarios for the ESB

Tomorrow I will be doing a joint webinar with Asankha Perera and Ruwan Linton about the WSO2 ESB. We will be showing how to handle some standard scenarios:

• Converting between legacy file formats and message-based systems
• XML transformation and message augmentation
• The "pushme-pullyou": using polling techniques to link database applications with live systems

The aim of this webinar is to give attendees an insight into how to handle some common scenarios with the ESB and also give a headstart on your own projects.

If you missed the introductory webinar I ran two weeks ago, that is being repeated on Thursday 3rd July. Apologies in advance to US folks heading off on their holidays!

You can sign up to both events here.

SOA Governance and Open Source Governance

SOA Governance is one of those great titles - it makes it sound like something incredibly difficult is happening. And the reality is - that in a large organization where SOA has grown up without controls - it may be difficult. But that doesn't mean it has to be. The basic principles are simple.

What are those basic principles? Open Source development principles!

The reason SOA governance is important is that SOA is inherently empowering. It is about enabling teams to take ownership of their own business services. Of course the problem is that you can't empower Bob without empowering Joe. That means that Bob has got to trust Joe, and Joe has to trust Bob.

Now Open Source developers are naturally dispersed teams who are empowered, and who trust each other. In Apache we talk about Meritocracy - which literally means giving the governance to the people who have merit. But it isn't just based on having wonderful smart people - its also based on processes and systems.

The main systems in place for OSS governance are simple:

• A shared repository with correctly managed access rights, accessible via command line, tools or website
• Versioning of every change so broken code can be rolled back
  
• Notification of code changes through publication
  
• A shared forum or mailing list for discussion
• A good build system that manages dependencies
• Validation of code through unit tests
  
• A well defined release process

These simple aspects create a framework for a community to govern multiple components across different geographies and teams. And it works. If you want proof, simply look at Apache's productivity - or Codehaus - or better still - WSO2.

What does this mean for SOA? Let's take each of those aspects and see how it maps to our SOA Governance solution - the WSO2 Registry:

• Shared repository: this is what the Registry is. It is a shared repository, with fine grained access control, and can be viewed as a website or via command-line/programmatic tools
• Every change to a resource is fully versioned, and you can checkpoint a directory at any time, capturing the exact state of all resources in that tree
• Notification of changes - you can subscribe to any aspect of the registry and repository using Atom, or extend the system using well-defined plugpoints to use email or other publication systems
• Even better than a mailing list, each resource has its own place for comments. You can subscribe to all comments across the system, but each comment is closely tied to the resource it applies to. This maintains the history of the discussion directly against the resource.
• Dependency management - both automatic (this WSDL uses this Schema) or simply added by the developers, this allows impact analysis - which WSDLs are affected when I change this Schema
• Validation - we now have build in WSDL validation and WS-I compliance testing, and the system can be extended to support any level of validation of resources (e.g. WADL validation or Policy checking)
• Release process - you can simply define a lifecycle for resources (or different lifecycles). These can be as simple as promote/demote, or can build in rules to invoke different users to authorize.

These simple models are the basis of a properly managed and well-defined SOA Governance process - and its available now, completely Open Source under the clean Apache License. Download the WSO2 Registry 1.1 release now!

Google Analytics finding my trackbacks

I just installed Google Analytics on this blog - so be warned - I'm tracking you!

Anyway, its telling me the referrer URL. And from that I'm spotting trackback's on my blog entries. I just noticed I got picked up by a W3C blog written by Karl Dubost - picking up my blog entries. I'm pleased, because this was a serendipitous outcome of getting web analytics that I wasn't expecting.

Progress buys IONA

It seems that Iona is no longer in limbo - Progress Software are buying Iona for around $100m in actual value.

Back in April 2007 I joked about the perennial problem: you wait ages for a bus, and then three turn up. In Iona's case they had Artix, ServiceMix and C24. Now Progress has to somehow deal with the ESB capabilities of Sonic, Artix, ServiceMix and C24. Its going to be interesting to see how they position four ESBs to customers. Or is it five? Or maybe six? Sorry I forgot that James Strachan often says people consider ActiveMQ an ESB. That would make seven!

I can only imagine they are going to have to cut some of that technology.