Planes, Trains, and Automobiles | JBoss European Tour 2011 Part II
Well, we last left our heros in Sofia embraced by the charming hospitality of Yoana Ivanova and the rest of the Java2Days crew. In the afterglow of a successful JBoss presence at the conference, Lincoln and I allowed ourselves to be persuaded to stay out with community contributor Ivan way past bedtime; night turned to day without rest inbetween, and Team JBoss was again on a plane set to catch up with the Parisians.
France was the one gap in my schedule devoid of conferences or technical engagements, and I was thouroughly amped to see the city. Of course, when you’re staying with Seam Social Lead Antoine Sabot-Durand’s family, the experience gets amplified as we had the chance to geek out along the way. Throw into the mix old friends like Hibernate/data guru Emmanuel Bernard and new ones like Java EE author Antonio Goncalves, and now we’re cooking with gas. My apologies to the ParisJUG community as we were only in town for the weekend, but I’m hoping to meet your thriving group in the flesh some day sooner than later.
The discussion on this leg that held most interest for me stemmed from a question raised by Antonio on the relationship between JBoss projects. Through the past few weeks I’ve had the chance to think on this further, and I’ve come to this: upstream projects should be given as much freedom and flexibility as can be permitted.
I don’t believe we do the community a disservice by giving as much leverage for individual projects to use whatever tools and mechanisms they deem appropriate. Build systems, documentation delivery, SCM, development methodologies, you name it. I’ve been a part of great projects that run “my” way, and I’ve struggled to work alongside equally great projects that run counter to my every instinct. That’s the beauty of letting a community shape the direction of the project; it becomes a breathing organism which molds to its creators’ tastes. Unification of projects is not an important construct to me. It’s Darwinian. Some undertakings will fail, either because they’re conceptually flawed or poorly run. And we should let them.
That’s why we have the notion of products. For the Enterprise we need to take these ideas and code which have matured, and focus on a streamlined delivery process that makes everything look the same. So if you ask me, let projects run free and arm them with all the tools they need to succeed. Make suggestions for how they should build their communities. But impose judiciously. And allow the supported product to fit the need for customers who rely upon the unification services.
In that light, I’m awfully proud in particular of my teammates Dan, Aslak, and Lincoln. I think about the type of outreach we do, about the type of investment in building the community and the thought that goes into all of the stuff that doesn’t involve code. Dan and his wife Sarah singlehandedly introduced a much more radical and effective presentation platform for us. Not to mention near-daily emails containing some allegory to building software. Aslak is on the IRC channels daily, and his engagement has grown from fielding user questions to coaching ARQ developers. And Lincoln took the task of bootstrapping projects and turned it on its rear-end, making Forge an all-out plugin community with limitless bounds.
For my part, I think the emphasis was always placed on limiting the barriers to entry for new contributors. It’s not a deceptive formula: define small scopes, bite off little bits at a time, and focus first on the API and its use. I’m a simple guy.
But I digress. Paris. Also there was wine. And laughter. The two were likely related.
Speed is to become a theme starting in the next installment, after Linc and I hit the TGV outbound to Stuttgart to meet up with Da Germans.
S,
ALR




