there.is.only.xul

I have spent the last few days hacking a Firefox extension. While the platform is pretty cool and extensible the documentation is sparse to say the least. Even searching the web the amount of information is very sparse. This is proably an indication of the platform maturity.
However the number of extensions is however growing (a very good sign), so learning by readiing code demonstrates a key to the success of open source - building on the shoulders of giants.
With a little effort I was able to hack the webdeveloper extension and add a few new features that some of our design team needed. Many thanks to Chris Pederick for all his hard work and making his tools available.

It is really nice to be able to build on a full HTML/CSS rendering engine. I look forward to seeing a lot of great applications come from the platform. Once full EX4 support arrives with 1.1 it should be even better.

Open Source - Software or Services

The acceleration of adoption and acceptance of open source by the mainstream is accelerating see: Investors to commercialize open source and IBM buys open-source Java outfit Gluecode. These are major chasm crossing events and should be celebrated, and congratulations to all involved. However I question that this is the best model economic model for all open source projects. In fact I will argue that if an open source application project is a technical success it inherently will undermine the current economic model, based around paying for support.

The current thesis is that users of open source software will pay for support, bug fixes, training, consulting and other soft services. The fallacy of this model is that open source software has moved into the mainstream because a vacuum exists. Existing software is not meeting the needs of the users of software. I am not an economist but my instincts tell me that the need for open source software such as Linux, Apache, mySQL. JBoss, etc is caused by economic forces not by any altruism within corporations. Successful open source projects succeed because they meet the market needs, have higher quality and are easier to use and maintain than closed solutions.

I would argue strongly that the most efficient companies in the next decade are those that minimize internal resources IT by maximizing the use of external services. This is a demonstrative trend - we have moved from internal data centers to shared data centers to managed applications within the last 8 years. The economics of shared resources are just too powerful to ignore except for the largest companies. Why does anyone want to hire a set of DBAs to manage a customer database when they can get it done for a few hundred dollars a month - and scales linearly by usage. Why does anyone want to buy install and manage a set of servers when they can have someone do it for a monthly fee - add, change, delete based on need not educated guesses but on actual usage. In other words the utility model is here and it is the economic model for the future enterprise - the most efficient enterprises are the ones that will manage it best.

The key differentiation that I make is between open source solutions and infrastructure. Infrastructure is operating systems and web servers etc. Solutions can be anything from an SFA application to an XSLT transformation engine. The model for the two is orthogonal - infra-structure has to be everywhere to power the grid ( like redhat and Apache) but applications like openCRX or XOOPS to pick a couple from SourceForge should not require deployment - they should just be usable. A recent posting from Tim Bray points out that half of IBM's income comes from consulting - the rest is from sales of hardware and software, with software being only about 1/6 of the total. To put it another way 25% of the cost is license fees the bulk of the costs 75% is from installing and getting it to work. No wonder there is so much shelfware around - a lot cheaper to leave it on the shelf. (Note: this is a somewhat simplistic argument but experience has shown me it is essentially correct).

Returning to open source - the drive for open source projects (IMHO) is to create software solutions that due to its open nature, benefits from continuous peer review and a Darwinian evolutionary process. The current approach to deriving economic benefit is inherently the antithesis of open source. The drive in an open source project is to make it more accessible and through peer review high quality - when these goals are achieved it becomes widely adopted. This inherently(and correctly) diminishes the value and need for support services. Putting it another way the most successful open source projects are those that are most accessible and have the fewest bugs and hence the least need for support. The current support model means for open source application projects to succeed economically they must deliver and continue to deliver software that requires support.

There is another way however that actually combines the best of both worlds and provides companies with a clear economic model for paying for services and enhances the ability of the open source community to deliver high quality software and if appropriate reap an economic benefit from their labors. For the majority of open source projects the model should be services not software. By services I mean applications that run on a managed grid that can be accessed by anyone. The applications are accessible as individual services or collections of services this attacks the largest area of costs that enterprises face.

This approach provides a few interesting benefits:

1. Drives developers to solve business problems rather than point solutions (how many POP services are listed in SourceForge?, why do we need so many - some is the Darwinian process at work. However the accessibility of all these projects is an issue.
2. Provides an economic model for developers (and potentially investors) to share in the benefits the work is delivering and motives the correct model - easily accessible bug free software has higher value for both the consumer i.e. I will pay higher for an easy to use robust service and open source developers want to deliver accessible highly secure and robust services.
3. The open source model still works - I can look at the code and submit fixes and accelerate the development as needed.
   
4. There is a reason to pay on going fees for the same high quality solution - the model is now about usage and the service level agreement (SLA). The higher the demands on the SLA the higher the potential fee. I believe this aligns the development and user community better than any other model.
   
5. The development effort is now focused on a single platform and not on how many platforms can I make it work on. It is focused on the solution not on how to deliver the solution onto multiple platforms.
   

This alignment of the economic model and the drives of the open source community is critical for the long term success of this model. Improving the quality and accessibility of applications while removing costs from the IT infrastructure is going to make enterprises more efficient and hence more profitable. Without this alignment the current wave of investments in open source projects will just be more VC roadkill as they are attacking small (25%) problem not the big (75%) problem. Instead of changing the model they are thinly disguised System Integrators that have experience in a specific set of technologies.

Dynamic Languages

In Phil Windley's Technometria | The Continuing March of Dynamic Languages Phil suggests that Scheme is a great dynamic web systems. I have a fond spot for scheme as way back I worked on a system that used scheme as a dataflow language for creating analysis tools. It was based on some cool research a bunch of guys at MIT had done. It was extremely flexible and we could do anything with it. Coupled with XML I think it is a very interesting avenue to explore. I look forward to hearing more about Phil's adventures.

A small understatement from Stefan

I just LOL when I read footnote [5] in Stefan's posting RPC-style Web Services. The only thing that compares to (and exceeds) the complexity of Corba is OLE2.

WSDL 2.0 - First impressions

After reading Dave Orchard's Blog: WITW WSDL 2.0 HTTP Binding I downloaded some of the WSDL 2.0 specs to read on the train. I am pleasantly surprised as compared to WSDL 1.1 it appears much more accessible. Whether my positive impressions are due to too much reading of WSDL 1.1 not sure. Mark Baker as always has a very pithy comment that aside all the people involved should be congratulated for their hard work.
Congratulations aside, I question the idea of a "single SDL to bind them all". So I ask the question, why do we need a single SDL, when would I need to use both? It is certainly a nice idea but as technology evolves, different areas typical move at different rates and evolve in different ways. Linking them usually tends to be a bad idea.

Simplicity - Just ask why

One of the most powerful questions I ask myself (especially) and others in reviews is why is something in a project. As engineers we have a tendency to like shiny new things, elegant abstraction etc.

As is pointed out in Quoderat » Blog Archive » Burden of Proof injecting simplicity is sometimes about just asking why something should be added or why is there a need for a layer of abstraction or why is there a need to make the solution completely generic. In many cases there are very good reasons to add abstraction etc.

We need to always challenge ourselves to see if we are solving a real problem - so just ask why.

46,213,000,000.00 things to fix

This is classic ongoing · $46,213,000,000.00. Several years ago evaluating a J2EE servers I found this to be so true, downloading, installing and running test program for JBoss - under 10 minutes. While WebSphere the download was 14 times as big and getting running was days (i.e. call IGS). Is WebSphere so much more capable than JBoss - I doubt it and given IBM's recent purchase of GlueCode they might have seen some of the light.

Dissolving boundaries - inside and outside

Phil Wainwright comments on dissolving boundaries Loosely Coupled | Dissolving boundaries | May 6th 2005 2:12pm. I think we need to make a clear differentiation between inside and outside boundaries.

Inside the enterprise the CIO has some degree of the framework between the silos and can manage the necessary change to define the fabric to achieve loosely coupled services architecture.

Outside the enterprise the CIO has little control (but has economic power) of the fabric. Here though is where there are compelling economic benefits for a CIO to use external services (see: Why Integration as a service?) or consider the economics of Salesforce versus Siebel. The long term winners here are going to be the providers of business services that destroy the previous economic models. The tools vendors need to change their POV from being the center of the universe (or single religion) and become enablers of wide scale service integration that provide dramatic economic benefits to the enterprise.

Resedel - Updated

John Cowan's entry into service definition language Recycled Knowledge: Resedel. Looks good I think as I am better with Schema than RelaxNG. (Update - thanks to trang here is a XML-Schema version of Resedel resedel.xsd)

Biggest question is why translate HTTP-GET et al explicitly into CRUD - expose the URL verb, another layer of abstraction can be confusing.

Service Descriptions - Just the docs?

Couple of interesting posts: Dare Obasanjo aka Carnage4Life - On Replacing WSDL with Something Simpler and Mark Baker- ongoing - SMEX-D.

Both make the point that having an interface language for services should not do very much. From my POV I want primarily a means of getting accurate documentation on the interface (and also providing it to consumers of services). For all its warts Javadoc was a great step forward as it provided a way for developers to provide documentation will minimal effort. Until Javadoc the best examples of standard docs that I had experienced had been man pages, and some Lisp environments.

For services to be propagated widely there is a need to provide documentation that is easily created and kept up to date. Perhaps this is the starting point for a service description?

the simplest thing that can possibly work

Quoderat » Problem-first design - great POV and quote

Service Descriptions - There does not need to be just one

There has been some really good analysis and thinking about service description languages recently by several smart people (Tim Bray:SMEX-D, Norm Walsh:NSDL, Mark Nottingham). Everyone of them makes some excellent suggestions and brings a unique POV. One of the challenges that everyone is assuming is that there needs to be only one service description language. I challenge this assumption and suggest that more than one is actually preferably.
The are a few reasons for wishing there should only be one service description language:

• We have a mind set that is framed by the Web publish-find-bind triangle where we assume that magic happens by everyone automatically discovering services and magically binding to them to solve complex business problems. This implies that there is a many to many relationship between services - all services need (and can) talk to all other services. In the real world this is more like one to a few or few to a few - a slight over design.


• There is the burning desire for protocol independence - between companies there is unlikely to be a placement for HTTP/SSL anytime in the future. As the enterprise architecture is slowly being decomposed into services provided by outside organizations I would suggest having a single transport is more important than have transport/protocol independence. If the transport information is cleanly separated from the message there should be no issue in replacing it with a different transport - a good example is EDI and AS/2
  
• The complexity of integration is not in the communication of messages it is in the integration of the semantics after the message has been received. Currently we are doing several integrations a month with a wide range of systems. The message delivery is not the problem it is the semantic meaning of the messages and this is in a single well defined vertical.


• Tool development has always been a good reason for having a single set of standards that all vendors build. The tools are complex because the service description is complex, and there is a lot of complexity introduced by RPC. If we focus on the message (where the real integration occurs) there are really good tools available, XMLBEANS for Java does a truly great job of providing a binding between XML and Java, similarly XSD for .NET and I am sure there are many others. These tools work on basic schema's and are generic tools - rather than specific more complex tools.

One of the really good aspects of the service description languages described by Tim Bray, Norm Walsh is that they use the same vocabulary as the transport i.e. HTTP -this makes it a lot easier to understand as it does not add another layer of verbal indirection. This reduces the learning curve and hopefully the ambiguity. Having several service description languages is not an issue if they are all in xml they can be transformed from one to another easily. As the transformation is a design time dependency and not runtime a runtime one there is no performance penalty. The major issue may be loss of meaning but there are only a limited set of MEP's so this should not be a long term issue.

The tendency today for web services is to add more features and hence the complexity is increasing. Shift the focus to how simple they can be and reduce complexity, lets see how easy it can really be.

The focus must be on the communication of information and not overly abstracting the service descriptions to a point where everyone just gives up and writes word documents.

Building knowledge from parts

Google has done a great job of decomposing knowledge and making it accessible but is it possible to build knowledge from parts in an automated fashion.

The first questions two ask are 1) Is it possible to build useful knowledge for components in an automated way - (Rooter a machine generated would tend to suggest otherwise:-)) 2) why would we want to do this.

For me the why is the information overload caused in large part by change. A tool to categorize and filter information intelligently would be a better Google. Navigating down to page 15 of a Google search to find a nugget is not very productive. Though compared to the alternative it is a major step forward. Being able to compare and contrast becomes even more interesting an intelligent Google Fight (thanks to Mark Baker for the pointer) may be an interesting starting point. Rather than distill knowledge provide the ability to contrast and compare POV - something our political process badly needs.

How about parallel news tickers showing pros and cons on a viewpoint to help decide on a course of action. How about an uncertainty measure - we all know the uncomfortable feeling of not having enough information to make a decision - does it help to quantify. We live in an imprecise world is it possible to measure/estimate the degree of ambiguity?

So search is great but it is just the start - we have parts now what are we going to build to create new knowledge and understanding?