Things to Keep in Mind as a Vert.x Observer: You Don’t Know Anything

Great, so everybody in programming land is now jumping up and down about the evil RedHat and VMWare and freaking out about vert.x.  Predictably, all these commenters appear to be reactively comparing this to the Judson schism.  (Ugh.  It isn’t the same.)

In Chicago we have something called a “Gapers Block” – a term that a traffic reporter uses to describe a traffic jam due to people stopping to see the carnage.   This vert.x situation is today’s Gapers Block, and I’d suggest that people stop staring and try to keep traffic moving.

I know I’m going to get a lot of flack for writing this post, but 24 hours into this vert.x situation and the whole thing is starting to smell like Hudson v. Jenkins all over again.  Or is it?  Vert.x isn’t Hudson.  It doesn’t have nearly the following that Hudson had.   It is interesting, yes?   But, 95% of people jumping on this “trending topic” on Twitter and Hacker News probably don’t use it.

If you don’t know anything about the relationship that exists between Tim Fox and his former employer, you should stop pouring gasoline on the flame.   You don’t know anything about the situation between Tim Fox and his former employer so here are some things to keep in mind:

  • You have no idea what sort of employment agreement Fox was covered by when he worked for VMWare.   You don’t.
  • You have no idea what sort of actions Tim Fox took to inform his employer about his plans surrounding vert.x.  You just don’t.
  • You are an observer to a public open source struggle, that’s it.   Stop making ridiculous statements about situations you weren’t interested in yesterday that are founded on abstract ideals of open source and freedom.  Remember this: companies are not evil.

For VMWare and RedHat, you should reconsider.   I understand that you may have valid claims on vert.x, I do.  But, the project doesn’t seem large enough to warrant this much bad PR.   The project is Apache licensed, why don’t you just fork it, rename it, and don’t make such a fuss.   It isn’t like there’s a huge community to schism at this point.

For Tim Fox, this isn’t Hudson.  From what I can see there are few vert.x users, and you dominate the commit history.   If you are going to try to enlist the public in your struggle, why don’t you publish the following documents:  (1. Your employment agreement with whoever you worked for when you created vert.x, 2. Any legal documents you may have been served with.)   Playing this out in the court of public opinion isn’t a great option for you as both RedHat and VMWare do a lot for the community and have supported open source for years.

Hudson was different, it was already the most important open source Java project when the troubles started.  Vert.x, not so much.    Also, vert.x is very clearly covered under an Apache 2.0 license.  Fork the thing, rename it, and be done with it.

Interview with OpsCode’s Jesse Robbins up on Radar

Go read my interview with Jesse Robbins on O’Reilly Radar. Robbins is the Chief Community Officer at OpsCode, the company behind Chef. In this interview he talks about how the category is developing, how many people are aware of technologies like chef, and a space-age use of Chef to automate the creation of super mad-scientist computing clusters. Enjoy.

OSS in the Enterprise

I’m convinced that OSS has been transforming what we call “The Enterprise” for a few years. It isn’t that businesses are evaluating OSS on purely economic terms like ROI, it is that the individuals who are starting to manage Enterprise IT efforts are OSS participants. They have been “convert” so to speak. The next time you read traditional analysis of OSS in the Enterprise consider that comparing OSS to proprietary software isn’t a direct (or even valid) comparison.

When you “consume” OSS you are participating in an ecosystem even if you don’t fully appreciate it. This participation brings with it an awareness of OSS that transforms your approach to software development. “The Enterprise” doesn’t exist apart from the people that run it, and it is the people that have been transformed by OSS.

I’m opening up this thing… Common Java Cookbook

As promised, I’m opening up the license for the cj-cookbook. I’m starting out with Creative Commons Attribution-No Derivatives-Non-commercial 3.0 US. So, I think that this license is a bit Draconian. It essentially means: “Can’t sell it, don’t use it for training, don’t change it, and tell everyone I wrote it.” Doesn’t that seem a bit vain for an open source project? I might relax the license a bit by dropping the NoDerivs clause, but I’m still mulling it over. Does anyone reading this post have any particular feelings about what license this book should be under? Does anyone want to challenge me to release it under ASL 2.0? I have been critical of viral licenses in the past, so it would be ironic of me to release it under the GPL Documentation licenses.

Today I…

I’m sick of writing books behind walls, it’s time to bring it all out into the open.

Open Source Application Ideas

I floated an idea to Mike Loukides a few weeks back of people posting ideas for applications and systems in a public forum – An Open Idea Exchange. Ideas that they would like to see implemented or that they themselves are considering as possibly interesting projects. Maybe there would be a site somewhere called “IdeaExchange” (what an awful name), but the idea is that there is some sort of social site where people communicate and collaborate on a set of open-source “ideas”. Whether the same set of people would be actively involved in creating an open source implementation of an idea, who knows? Maybe the site would be limited to the development of ideas, that’s it. If some entrepreneur wanted to come along and take one of these ideas of the shelf, implement it, making a “bazillion” dollars in the process…. great. The goal of the site isn’t to make money, the goal of the site is to develop ideas for applications in a transparent and open forum. “Open Source Application Ideas”.

A Reaction to “Startup Culture”

It still doesn’t make any sense to you, does it? I’ll take a step back and describe the problem I’ve noticed with “startup culture”. Part of the problem with the “startup culture” in the America is that it revolves around the idea of “protected” intellectual property. Companies and individuals never have an incentive to share an idea with a community and develop ideas in a way that would benefit from the collective input of a group of users. All too often, a great idea is hatched in someone’s garage in Mountain View, this idea is kept secret, maybe the idea is developed a bit and turns into the seed of a company. More often than not, these ideas decay into nothing more than isolated bursts of genius. Maybe an engineer has a great idea for a game changing way to index and search images, but they don’t have enough time to take a few weeks off from work to implement the idea and nothing comes of the idea.

Very rarely, a good idea turns into some poorly named startup with more money than is reasonable and no rational path toward profitability. This is the problem I’m noticing, too many times I’ve seen great ideas in the form of over-hyped, all-but-doomed, TechCrunch-nominated startups and I’ve wondered if there is a better way for a community of users and participants to come up with good ideas for applications.

Open Source Beyond Software

I’d like to find a way to start a community of developers and engineers who have little interest other than seeing good ideas realized without getting distracted by commerce or commercialization. Does anyone else want to see something like this? A place where people can discuss and develop ideas for the applications they want to see implemented?

I understand that this is a Utopian and somewhat idealistic idea, but I’ll be damned if I’m going to sit around and wait for a collection of poorly named Silicon Valley startups take good ideas and turn them into profitless, proprietary solutions that make someone else a ton of money between the time they get an initial investment of capital and the time to invariably fail.

Making Maven less "curse-worthy" (Porter’s terse branch)

Brett has some good ideas to create a newer POM format that relies more on XML attributes, I’m also thinking about different representation formats. Why not start thinking about allowing people to innovate and support even leaner alternative formats like YAML? Eric wrote something of a preprocessor, but why not open up the code that reads the model and make it pluggable? Isn’t this the point of using something like Plexus? And, even if it doesn’t fall into line with what Maven’s leadership wants, wouldn’t it make sense to allow someone to scratch this particular itch.

Just proposing the idea of pluggable POM parsers provokes general disdain. Jason would never want to allow “Scripting” or “Ruby-specific” formats for POMs as it would be a “disaster”. (Nevermind YAML is a hierarchical data structure that has little to do with scripting. It can be parsed in C, Java, Python, Ruby, Perl, Javascript.) Michael McCallum doesn’t want to allow POM innovation because allowing for POM innovation would make it more difficult to know if the people you were hiring really knew what a POM was. (Open source driven by corporate HR, that’s exciting!) Several arguments about how allowing for new POM formats with break Universal Understanding.

But the discussion is interesting… there’s little discussion of Brett’s code. The thing to realize about open source development lists is that maybe something like 25% of the subscribers have ever even bothered to checkout and build the code, the remaining 75% of readers are there to feel important. In the interest of contributing to the discussion, here’s some feedback for Brett.

Feedback on Brett’s Branch

Brett’s changes start in DefaultMavenProjectBuilder he introduces a ModelReader which takes care of reading both 4.0.0 and 4.1.0 models. Instead of handling the Xpp3 parser errors, this new ModelReader throws a import javax.xml.stream.XMLStreamException if there is a problem parsing some POM XML.

1. ModelReader makes sense, and it’s a change for the better to move remove the code to check the model version from the DefaultMavenProjectBuilder. To see what this class used to do, look at DefaultMavenProjectBuilder (from trunk) and search for “checkModelVersion”. Yikes, good move to get rid of that.

2. Make ModelReader an interface, move the current ModelReader to DefaultModelReader. Even though the majority of Maven overlords don’t want people to innovate wrt POM format, there’s no reason to close the door on the idea entirely.

3. (I know this won’t happen) but it would be useful if DefaultMavenProjectBuilder didn’t have to catch an XML parsing exception. Maybe a ModelReadException that contains the underlying exception that caused the problem.

4. (I also know this won’t happen) move everything related to XML parsing (“ReaderFactory.newXmlReader(file)”) into the DefaultModelReader implementation.

In general, I think Brett’s terse branch is a move in the right direction, it would make the process of customizing the format easier, and starts to tackle the problem of tight coupling between the Modello parsers and Maven core.

There is hope (from Atlassian)

Don Brown chimed in:

“Whether an attribute-based design is “proper” is a less important question than what makes Maven more usable. Form should follow function. What users care about is more readable POMs, less typing, and less clutter. I’ve been really impressed with the Maven team adopting a more programmatic approach to Maven recently, and this change will go a long way to making Maven more usable and less curse-worthy.”

Couldn’t have said it better, “what users care about is more readable POMs, less typing, and less clutter”.

Israfil Mojo: A Flex 3 Plugin for Maven

I’ve never been more impressed by a Maven Plugin. Seriously, the Israfil Flex Maven Plugin is both well designed and well documented. take a look

It allows you to separate Flex projects into libraries (SWC) and applications (SWF). It integrates seamlessly with the technology-neutral features of Maven. Maven doesn’t care if you are working on Java or if you are working on Fortran. This is the first example I’ve seen of a technology other than Java working so well with Maven.

So, if you are looking for a way to seamlessly integrate Flex with Java. This plugin is for you. More fodder for my prediction that Maven’s second-coming is upon us.

Maven and Docbkx from Wilfred Springer

Had an interesting few days getting the Docbkx Maven plugin from Wilfred Springer to render the Maven book. It works well. I started out passing customization options to the plugin, but, in the end I decided to do most of my customizations using the htmlCustomization and foCustomization properties.

Another note is that version 2.0.8 of the plugin uses Apache FOP 0.94 which was throwing a troublesome “missing entity” error. I ended up stepping down to version 2.0.7 and my problems vanished. I’ll try to post a link to the project (and the final rendered output) later.

Battling JvYAML, Moving to JRuby 1.0.3, Reverting.

Spent all day trying to convince JvYAML in JRuby 1.0.3 to cooperate with me. I got this bone headed idea that Ola’s JvYAML 0.2.1 was too old to bother with, and decided that I was going to stealthily introduce JRuby into a project I was working on under guise of YAML.

Some background, the project in question uses ActiveMQ for JMS, and we throw messages around as TextMessage objects in a YAML format to make interoperability with Ruby messaging consumers and producers easier….. Or, at least that was the original goal, it turns out that halfway into the project the idea of Ruby message consumers (via Stomp) was abandoned, so I have a series of Java components communicating using YAML and ActiveMessaging.

Confusing? A little, but actually not that bad, it makes debugging the internal messaging a little easier because you can see what is in the messages. The alternative would have been TextMessages with XML using XStream or ObjectMessage. I wouldn’t care between XML and YAML, but I didn’t want to use ObjectMessage because it makes visual inspection of intransit messages a PITA.

ActiveMQ is working out well, decided to go with a 5.0-SNAPSHOT a long time ago, and I just moved over to 5.0.0. ActiveMQ 5.0.0 still depends on a snapshot of ActiveIO 3.1, but *shrug*.

Anyway back to JvYAML, ended up reverting back to JvYAML 0.2.1 as the JvYAML in JRuby really isn’t meant for consumption outside of JRuby. Why? It looks like JvYAML doesn’t like String objects instead it tries to throw around ByteList objects (an extension of CharSequence). Because I’m trying to use YAML as a transport encoding for JavaBeans, this would only work if I screwed with my model. Blernk.

In other news, I fixed an interest bug with the Sysdeo Tomcat Maven Plugin: http://jira.codehaus.org/browse/MOJO-992