An Open Technology Manifesto

Many people have read Stevey's post. where he contrasts agile with Agile. Stevey does a great job of separating out the important "agile" value system from the methodologies and processes of "Agile" that were created to help the masses implement it.

Because in fact, it is in the implementation of agile that the values sometimes get lost. Ive' seen Agile often bundled with Extreme Programming tactics (Test-Driven Development, Paired Programming, etc.). which muddied the waters and resulted in teams claiming "agility" simply because they have junit tests. When people focus on processes, tools and methodologies too much, they can't see the forest for the trees.

Likewise, I believe we need a similar separation between values and implementation in "open development". In the details of the implementation, there are decisions about licensing (GPL or Apache?), and community (Java.Net or Sourceforge?). These can be argued just like people argue over the details of Scrum vs. Lean Devlopment vs. RUP. But in the end, "open development" manifests itself more so within the attitudes of the team members, than in the implementation decisions -- just like "agile".

Thus, humbly, I'd like to propose just such a manifesto:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Open discussion over closed "white-paper" analysis.
• Collaborative contributions to existing efforts over proprietary (re)invention.
• Open sharing of experiences over knowledge hording.

These combine with an overarching desire to commoditize the lower-level functions of the software stack, allowing all software development (and service-delivery) to focus on ever harder more valuable problems.

Enlightened developers often embrace the above values without knowing it, just like many of the same are inherently agile (in the "move fast and react fast sense of the term"). Others operate with a very closed mentality, despite the fact that sometimes they've "open sourced" their code.

For example, we often see "white-paper" analysis performed by the evil genius architects that lock themselves in a room with their crystal ball, carefully considering all options, finally emerging with an architecture that accounts for all the requirements, *and* all of the unforeseen changes to come (notice the paradox). Meanwhile, the enlightened developer has spent the same time discussing the options on a mailing list, effectively forcing some of the "unforeseen" changes forward in time by soliciting input from others and adopting suggestions (even if they don't directly address existing requirements).

Likewise, once an enlightened developer accomplishes a feat, he/she will blog about it to advance the productivity of the community at large, whilst the less enlightened will add this to their little secret bag of tricks enhancing their "job security". (the same developer goes on to prove black is white and gets himself killed in a crosswalk)

I was in diapers when the pioneers were doing the real work on open source. So I feel presumptuous even suggesting such a manifesto and I certainly don't intend to even hint that these are novel thoughts. I'm sure the likes of Eric Raymond and others have been espousing such values for years. My only point (if any) is that the Agile Manifesto did a great job of distilling agile into four statements that could be internalized by all. Open Development might be served well to do the same, separating it away from the "noisy" licensing debates discussing freedoms, and capitalism.

FWIW.

JBI: Catch the second wave...

If people remember back to the early days of Java EE (J2EE), there was a lot of promise, but a lot of frustration. I still have mental scars (and a slight eye twinge) from the countless hours tracking down typos in deployment descriptors. But, we were willing to endure the pain because there was a lot of power in the platform.

And as a model, J2EE was solid. Sure, there were squabbles over the value of different parts of the model (e.g. Entity Beans), but the general abstractions and approach were incredibly valuable, as evidenced by its success. JBI is similarly positioned.

However, mainstream adoption requires not just a solid design model . Mainstream demands ease of use, immediate gratification, and passionate community support. This is the fundamental appeal of Ruby/Rails and why J2EE struggled in the beginning. In the beginning of J2EE, it was a week long effort to get an EJB deployed. Meanwhile, Rails has caught on like wild fire because it takes less than 10 minutes to get an entire n-tier application up and running.

In an effort to learn from this, independent of the actual implementation communities (Apache - ServiceMix, Java.Net - OpenESB, etc.), we've created a JBI community site jBIZint, where the various implementation communities can come together to discuss common needs that will improve a user's over all experience. If this sounds like something you would like to be involved in, please join the mailing lists.

As an example, there are two movements afoot that will improve JBI adoption and ease of use. The first is a movement to standardize the diagramming technique for service assemblies, and the communication between them. Much like SCA has done, a standard diagramming technique will allow system designers to communicate effectively, the components, meta-data and communication paths of the services in the system. (Again, please join the discussion on the mailing lists to get more info)

The second movement is to get an "easy-install" package management system in place akin to Debian's apt-get and maven's repositories. (credit Bruce Snyder for the idea). This would make it simple to install components through tooling (e.g. Eclipse, NetBeans, or command-line). The package management system would pull down the component and all of its dependencies (e.g. shared libraries), perhaps even a sample service unit.

Combining standardized diagramming with an easy-to-use package management system should make it even easier to pick up one of the numerous "10-minute" tutorials on JBI, like Chad's XMPP-RSS Demo, and get it up and running in 2 minutes with an understanding of how and what you did. =)