Standard background - I believe in open source, always have and always will.  With that in mind, the comments below are not a knock on open source, they are an expressed desire for better software experiences and better products.  I hope that some of the observations and learnings below will lead to better JBoss solutions as well as hope it helps teams in general reflect on their products and the message it is sending.

I had sent some of these comments around to my peers and former colleagues and there were requests to make this more visible.  With that said...

To set context - the following comments and thoughts comes from observing and pairing with a 'normal user'  on a relatively simply application migration.

JBoss Application Server (Enterprise Application Server or EAP) is your standard J2EE application server.  None of that is really critical to the rest of the content. For the rest of the post, 'JBoss' refers to this and 'JON' refers to a management system used to monitor JBoss.  This experience is with the Red Hat supported enterprise version of JBoss and JON.

JBoss, historically, had a heavy, XML driven configuration.  The release of JBoss EAP 6 introduced a command line interface which allowed scriptable configurations.  Awesome, right?  In my Continuous Delivery classes, I talk about the necessityfor consistency - this scriptable interface is a nice way to it. Plus, XML is prone to human error.  Great move removing these challenges.

But...

The command line interface (CLI) appears to be created as just a traversal of the XML (which is used for configuration) with no consideration for how people would want to use it.  APIs should be created based on use, not on data structure. For example, if a user wanted to configure the environment to allow jsp files to be updated without needing a redploy, they would need the following command:

/subsystem=web/configuration=jsp-configuration:write-attribute(name=development, value=true)

What  does all that /subsytem=blah blah blah mean?  What is an attribute and why am I writing it?  Here is a hint - subsystem, etc has a whole lot to do with XML nodes, and the attribute you are writing is...yep, an attribute in XML. This is not a low cost API to a new, casual user.  Compare this to more of the standard configuration tools like Puppet, where something like this might look like:

jsp-development => true

Or, a simpler, user based API - a REST service might be nice and self documenting.  The point here is your API should be in the context of how it will be used, not the context of your data..  Ok, so the CLI may not be ideal.  Lets move on

JON is the tool that is used by system administrators and operations folks to manage their environment - from deployment through monitoring - complete lifecycle.  From our previous observation with the JBoss CLI, we know that JBoss does not want us manipulating XML as it is risky.  Cool.  Lets take a common scenario - say you wanted to deploy your application to a cluster of JBoss servers.  How would you do that through JON?

You would need to create an XML descriptor of your deployment.  Yep, it is too risky to configure JBoss by manipulating XML, but your deployments...roll your own XML.  And that XML, while it could be reused, will be needed to be tweaked potentially for each deployment, let alone each app.  Don't mess that up.  More on that later.

The lesson here - be consistent in your message.  Don't create different experiences in the same product line.

Sticking with JON for a second here - say for example your application did not need high availability or the throughput of a cluster, so you are only deploying to one server (instead of a cluster).  Surely that experience would be the same...Nope.  If you are deploying an application to one server, there is another route you need to go by creating a 'deployment' similar to a datasource.  That is all GUI based, no XML needed.  Yep, different experiences depending on how you are deploying.  It's like if you are going to eat at a restaurant and if you eat the french fries one at a time, that is totally fine.  But if you want to eat two french fries at once, then you have to ride a unicycle while spinning a plate on your nose.

The lesson here?  See above - Don't create different experiences, in the same product, on different screens...

While we are talking about JON - remember that deployment bundle XML nonsense I mentioned?  Here is a fun observation.  If you do that XML wrong and target the wrong deployment location (something a new user might easily do) - if you then remove that deployment guess what happens?  How about you make it so the target servers cannot start because a dependent directory gets removed?  Did you guess that one?  Yep, you can cripple your server if you mess up the deployment.

The lesson here?  Don't allow your users to cut off their own fingers, let alone their own heads. Josh Kerievsky(@JoshuaKerievsky) talks quite extensively about safety in products (For example, http://www.industriallogic.com/blog/tech-safety-in-demarco-classic/).  This is far from a safe environment.

Back to JBoss, and this falls back into the consistent experience space.  JBoss has a way of isolating dependent libraries - really good, solid idea.  It corrects versioning challenges across dependent libraries.  But here is the kicker again.  Remember that XML you shouldn't be touching in general?  Yep, to use this feature to isolate libraries you have to roll your own XML.  Usually, with new users, this will be a trial and error exercise at best and is wasteful

The lesson here? Don't lose cool features with bad experiences.

There are other items I can go into detail here, but the main points are above.  Again, my intent is not to bad mouth JBoss - I believe in them and open source.  My desire is that they, along with software teams in general, consider the experiences they are providing to their users.  Price point may get you into some markets, but bad experiences will quickly get you out.

What do you think?