• jboss-deployers
• jbossas
• microcontainer
• vfs

I’m adding JBoss projects to my mirror set as I trip across the need to browse their source.  If there’s a JBoss project you’d like to see mirrored out of SVN, drop the URL to the trunk of the SVN repository in a comment on this post, and I’ll start slurping it.

I feebly attempted to direct 8 great guys and gals to further the goals of JBoss.org.  After the Codehaus, you’d think I’d be able to help build an opensource community with fun and flair.  But I came to realize that it’s hard to build a community as an active effort.  Instead, I think community develops as a by-product of a useful and well-run project.  And that’s under the control of the project leaders and contributors, not necessarily some external third party.

Back in May, I gave up being a manger.

Now, the day after Labor Day, fittingly enough, I’ll be jumping back into the world of JBoss.  But not as a manager. When I was burned out and felt like resigning, Mark Proctor and Sacha Labourey instead talked me into taking a sabbatical.  And I’m truly grateful to them.  Now, after unwinding for a few months, I asked to rejoin the team as an engineer. Through Sacha’s patience and budget manipulation, I’m once again excited to go to work.  I think JBoss should definitely be held up as a company that takes care of its people.  They could’ve easily given me the boot, but instead they’ve been extremely kind and accommodating.

So, what will I be doing?

After talking to Java developers and Rubyists alike, my first goals are to look at Rails as just-another-way to write J2EE apps (or “JEE” I reckon, these days…).  Yes, I know about (and plan to use) things like Warbler and JRuby-Rack.  Both are good things.

But I also have full control of the deployment environment, to build a stack to make it happier than “build and deploy a WAR”.

Through the miracle of AS5 built on JBossMicrocontainer, along with the awesome VFS bits, it should be possible to deploy a Rails app in-situ, right from your working directory.  There should be no reason to have to build a WAR while you’re hacking a rails app.  And deployment to a server should still involve capistrano (in my opinion).  Stick to the Rails way of doing things, but make it Java under the covers.

Various blog posts have shown Rails apps on Glassfish in 12, 10, or 5 steps.  My goal is to get it down to 1 step. And you should magically be able to pick up and use all the wonderful JEE bits that maps to the Rails functionality the Railers of the world enjoy, without having to be aware of the JEE bits.

Speaking with Mark Newton (the guy who runs JBoss.org now), it seems sensible to view Rails as simply yet-another-programming-model for writing Java apps.  The idea is to avoid leaky abstractions, so we’re not having to write some psuedo RubyJava application.

Once we’ve got that base covered, then we can make fun and exciting Ruby bindings to all the powerful JBoss tools, such as Drools, ESB, Cache or MQ.

I expect to have a bit of fun with this.  More fun than being a manager, certainly.

Gavin provides an exceptionally nice walk-through behind not just how Web Beans works, but why it works the way it does. He provides comparison to AOP features, and even demonstrates the recursive nature of Web Beans functionality being used to define Web Beans functionality. Meta-annotations are cool. Meta-meta-annotations are even cooler.

We’ve broken the talk into 3 easy-to-digest chunks:

• Part 1
• Part 2
• Part 3

Additionally, http://wiki.jboss.org/ has been moved off the old Nukes wiki and onto a more modern wiki. Along with being merged with the wiki that used to live at http://labs.jboss.com/wiki. Like many organizations, we’d ended up with too many. We probably still have too many. But now we have one fewer. You can thank Tomek for that.

Probably the coolest bit of tonight’s update is the new feeds subsystem created by Adam. You can check it out, and notice that you can now submit a blog for inclusion in our aggregator. Project leads have more control over their project’s aggregator, and we’re archiving everything we touch, now.

We’ve got our ideas page up still, or feel free to invent some great project of your own related to JBoss. We’re open to new ideas.

The JBoss guys have started gathering project ideas. If you’re hoping to participate in the GSoC, take a look, and maybe you’ll see something that’ll inspire you.

If you’re a student, the GSoC is a great way to spend your summer and get some bonafide open-source work under your belt. While being paid. Plus, you’ll get to work with top-shelf Java developers like Manik Surtani, Ales Justin and Tim Fox, amongst others.

So, get thinking about your projects, because the student application window is about to open.

Max and the JBoss Tools team have released version 2.01. What I personally find exciting is that this release sees bundles for OSX. The JBoss Tools project is what ultimately feeds into the JBoss Developer Studio, so you know it’s good stuff.

Also, Tom, Koen and the jBPM team (with the assistance of the .org designers) have published an updated site that includes a fancy new logo and some diagrams to help you get your footing in the world of BPM.

The first sessions of the day were packed and standing-room-only. People were spilling out of the JBoss Clustering talk presented by Bela Ban and Brian Stansberry. Greg Hinkle presented the JBoss Operations Network (JBoss ON), which, as announced previously, is working with Hyperic to create an awesome open-source systems-management system. Ales and Scott presented about Microcontainer’s new OSGi facilities. Ales also spoke about the OSGi bits of MC earlier this month with Mark Newton.

The afternoon sessions were wrapped up with the conference keynote. Emceed by Craig Muzilla, we heard from Jim Whitehurst, the new CEO of Red Hat for the last 42 days. He reaffirmed Red Hat’s commitment to invest in the JBoss division, its technology and its community.

Sacha Labourey reflected on our past, and spoke about the future of JBoss, including the Enterprise Acceleration initiative. Enterprise Acceleration aims to make JBoss as ubiquitous in production environments as it is in development environments.

Then, Sacha lead into an ultimately ill-fated demo. It was awesome while it lasted, but then, as is typical, the demo demons took over, and cut it short. Before that happened, though, Max Andersen demonstrated the power of JBoss Developer Studio by going from 0-to-60 in about 3 seconds. JBDS makes it simple to start a new project skeleton, complete with everything you need, and automatically deployed within an instance of AS managed by the IDE. The integrated Exadel WYSIWYG tooling significantly reduces the code/compile/test cycle. He expects another spin of JBDS this quarter to include the 4.3 version of JBoss Enterprise Application Platform (JBEAP).

Following that nicely, Julien Viet of the JBoss Portal team jumped up and did a quick demonstration of integrating JSF/Seam within Portal using the new JBoss Portlet Bridge project. He also was able to point out support for remote portlets using WSRP before the demo demons killed the power to the stage. The Portal team released Portal 2.6.4 just last week, and expect 2.7 sometime in the 3rd quarter of this year.

The keynote was followed by a festive cocktail hour in the exhibitor hall.

And all of that was followed by the BoFs and Hackathon. The BoFs were well-attended, the Hackathon was not, alas. Manik Surtani, Ales Justin, Mike Brock, and a few others dropped by the Hackathon for a while. Mark Proctor demonstrated the nice visualization, traceability and breakpoints provided by Drools Eclipse tooling during his BoF.

Overall, it was an excellent day, and at 4am, I’m simply worn out. An even fuller day awaits us tomorrow.

Awoke and joined the JBoss Developer’s Conference (the conference for JBoss developers, before JBoss World) this morning. Met the normal assortment of JBoss guys you’d expect to find at such a gathering. In addition to the developers, there were some non-developers present. This included Patrick MacDonald discussing our approach to the build and release process, and Andrig Miller addressing the differences between community and enterprise versions.

JBoss World itself cranks up at noon on Wednesday, and should prove to be exciting.

To help organize your attendance, you can subscribe to the agenda iCal we’ve put together. I suggest subscribing to it, instead of importing it, so that you can pick up any changes we make during the course of the conference. Go ahead and sync it to your Blackberry, or iPhone, or Android handset.

And don’t forget the Hackathon on Wednesday night. I know it conflicts with the BoFs, but the Hackathon runs until “late” and we’ll welcome stragglers.

Update: Max Andersen asked for the actual root gCal.  Here it is.

I’ll be working with Karsten Wade of Red Hat Dev-Fu to produce daily show reports. You can also follow along at home through my twitter. If you’re at JBW and twitting, leave a comment here with your Twitter URL, so others might can follow you.

See you there!

Yes, yes, I know it’s surprising that the superstars at JBoss might possibly write some buggy code. But we don’t always get a full 8 hours of sleep and a complete, nutritious breakfast. Plus, sometimes elves sneak in at night and play dirty tricks on us.

None-the-less, there’s some bugs needing squishing.

Check the announcement for all the details, but bottom line is you’ve got 30 days (until JBoss World) to find and/or fix as many bugs as you can. For that, valuable prizes may be awarded.

Now’s the time to head over to the Hackathon wiki, and start making some plans. If you haven’t bought your pass to JBoss World yet, you need to jump on that, also. There’s less than a month before we’re all hanging out in sunny Florida with the gators and Canadians. The agenda is published, so you can see that you’ll be missing a lot if you don’t come.

Working with Jon Atkins and Shaun Connolly who handle the .com side of the house, we’ve worked up some statements to help try to clarify it all. Additionally, James Cobb whipped up a pretty intuitive diagram demonstrating the way the open-source community is cherry-picked and how the rough edges are sanded off to create the supported bits.

With the winds behind us, we managed to make it to Schiphol airport in a record 6.5hrs from Newark. Not bad at all.

Met up with James Cobb, the kick-ass .org brand-manager/designer at the airport. We managed to keep each other walking around and awake all day to stave off horrible jet lag.

The wife and I stayed a night in Amsterdam before taking the train to the lovely Centraal Station area of Antwerp. If you’re looking for the ambiance of a Motel 6 with the convenience and bouquet of being beside the Greyhound Station, this is the place for you!

Once in Antwerp, we hooked back up with James, and met, for the first time, the Fabulous Five from Poland: Przemek, Ryseik, Adam, Tomek and Pawel (left to right). Mark Newton was present for a few days, but had to return to Switzerland early, unfortunately.

We ate a lot of frites. And waffles.

The Polish developers attended a lot of the conference talks, and we as a team had some great whiteboarding/brainmapping sessions about the future direction of JBoss.org-NG, as we’re calling it (more blogs to follow on that topic).

Somewhere along the way, the guys goaded me into doing the Java Black Belt competition at the Cap-Gemini booth. I managed to make it to the finals, and ultimately won a PlayStation 3. Unfortunately, it was a PAL-based Region-2 PS3, which is decidedly incompatible with my Region-1 NTSC lifestyle choices. It’s now living in Poland, along with a Nintendo Wii that Adam won.

I chatted up Crazy Bob and learned that we’d both lost our hats during the trip. A man without his hat is a sad sad thing. Luckily, I did manage to procure another. Also luckily, I have more hair than the other Bob.

I met Vincent Massol, Stan Silvert and Julien Viet for the first time. I met Emmanual Bernard, Max Andersen, and a host of other JBossers yet again.

During the entire trip, I managed to get yelled at a lot (hat shopkeeper, hotel matron, inn keeper, bar maid) and had that Alecia Keys song injected into my skull everywhere I went.

Overall, a success!

JBoss has a booth, and a bundle of core developers (and management) will either be attending or speaking.

Contrast that to Apple, who some people think is pulling back and away from Java.

For more information about these agreements, see this interview with Sacha Labourey. He explains the expected impact and benefits of these arrangements.

When you do a date-based operation using Subversion, it does a binary search through the revision sequence to find the revisions matching the specified dates. This binary search assumes the revisions are indeed date-ordered.

With the acquisition of Mobicents by JBoss, we’re in the situation of having to merge about a dozen repositories. Some are CVS, some are SVN. Good ol’ cvs2svn works well for the first step, of converting a CVS repository into a SVN repository. But now we have either oddly disjoint repositories, or conflicting paths overlaid one another.

I’ve always been a fan of mod_rewrite for Apache-httpd, and a SVN dumpfile has a lot of paths just ripe for rewriting. 1000 lines of Ruby code later, I’m able to announce Unwind. Unwind is a Ruby library, along with a command-line tool, for performing mind-numbing feats of repository surgery.

Since a massive conversion and rewriting is something that requires a bit of trial-and-error, the command-line utility is ultimately driven by a configuration file. Of course, with Ruby, it’s just a DSL created using instance_eval and blocks.

This configuration file will ultimate produce a single file (merged-repo.svndump) from multiple input dump files. Each source file can include()/exclude paths (based upon the original paths in that particular dumpfile). Each source can also use Rails-ish URL rewriting. The :something syntax matches 1 segment of a path, and is available as a substitution value in the output path for the rule.

The rewrite engine tracks all existing paths, and creates parent directories when necessary. SVN copy operations are fully adjusted both for the source and the destination paths.

Unwind automatically interleaves revisions to achieve total monotonically increasing time-ordering for the final repository.

Finally, before a revision is emitted to the output repository, addition include()/exclude() rules can be applied. For repositories converted from CVS, you may end up with a bundle of CVSROOT directories attempting to live in the same location. No reason to rewrite them to unique locations, as you can just exclude them before they get figured into the final output repository.

Unwind uses SQLite for organizing the meta-information about each repository and revision, while performing random-access seeks on the source dumpfiles to produce the final repository. While merging may be the common use-case, Unwind’s rewriting also makes it useful just for extracting bits out of a repository.

At this point, this blog entry is the complete documentation for Unwind. But feel free to browse the SVN repository.

I’ll be drafting some core developers, external contributors and users of JBoss projects to discuss the various aspects of OSS projects. We’ll compare the differences between projects that have community origins to those with corporate origins. We’ll look into the different management styles of both communities and projects. We’ll get some feedback from users and contributors, to provide a different perspective. It should be interesting.

Additionally, JBoss.org will be sponsoring a hackathon. This will provide a place for developers who seldom (if ever) meet in person to get together and write some code. Hackathons are a great way to learn a lot in a short amount of time or to knock out a major feature or improvement on a project. We’ll be publishing more information about this soon, along with a wiki page in case anyone would like to coordinate their activities.

Nor the Happy Cows of California.

I’m heading to Switzerland next week.

Finally, I get to actually use Dopplr. I’m one of those remote-type web workers, so this international trip is chance for me to actually have some face-time with my boss.

“Stop by my office before you go home” doesn’t work so well in a distributed company such as Red Hat.

First, if you’re wanting to meet some of the JBoss guys out in the Real World, we’ve mashed-up Google Calendar over at our Community Calendar Page. Currently it includes some dates to meet the Drools guys in Orlando, Romania and Sao Paulo, some Hibernate guys in Atlanta, Dublin and London, and the Value2 tour across North America.

Additionally, Norm Richards has announced Seam 2.0.0-CR1. If you’ve been waiting to jump on the Seam 2.x bandwagon, this is a really good time to check it out. Being a candidate-release, this could quite possibly be The Real Thing. If while digging around, you find a show-stopper of a bug, let us know in the forums or via JIRA.

We’ve also included a transcript, since both Gavin and Mark have those funny accents.

Back in the day, teaching myself how to program in C++, I decided to write my own scripting language. I’d tried (f)lex/yacc/bison, and they were either not friendly to C++, or not friendly to the way my brain works. Then I stumbled across PCCTS and recursive-descent LL(k) parsers. For once, the grammar productions seemed to make sense. The generated code seemed to be readable and make sense.

Praise be unto Terence Parr, creator of PCCTS.

Then he abandoned C++ for Java, and created ANTLR. Now it’s up to version 3.0. And has a book.

ANTLR is one of those libraries that you either love or have never heard about. You’ve probably enjoyed the benefits of ANTLR none-the-less.

• JBoss Rules rule language parsing
• Hibernate HQL parsing
• Groovy language parsing

Being able to create a parser for a new little language (or “DSL” to be hip and trendy) opens up a whole world when implementing new software. It makes it easy to think of formats beyond XML or CSV. Users get tired of being stabbed in the eye with XML’s pointy brackets.

YouTube | MPEG-4 (Video) | MP3 (Audio Only)

[youtube]SuO9m4qE9DE[/youtube]

First the obligatory “look how cool I am” section…

Name dropping

Misc

Drank too much with Hani of the BileBlog. Congratulated Cameron & John Purdy at the Tangosol party. Finally met Phil Dodds and Brett Porter, from DevZuz. Dan Diephouse and Paul R. Brown (”Yes, we’re the XFire guys”) had candy at their booth. Jason Hunter handed me an invite to the Google party, where I finally met Crazy Bob Lee (one of the damn nicest people ever). There I chatted with Ola Bini who is a man who makes me feel short. Re-met Jon Tirsen after a 3-year hiatus (the first hausparty in Amsterdam). Paul Hammant expounded on Mingle and other things over bowls of curry. Chatted with Matt Quail and Pete Moore of Cenqua a bit while absconding with Google t-shirts. Chatted with Matthew Porter of Contegix, the hosting providers of the Codehaus. Stood around (in my JBoss shirt) in front of the IBM booth chatting with Lauren Cooney. Met Guillaume LaForge and Graeme Rocher finally. Put some faces with the Exadel guys I’d worked with during the opensourcing of their products. Greg Wilkins reminded me the Codehaus SSL cert was expired (fixed now). Geert Bevin was as enthusiastic as ever at the TerraCotta booth. Ran into Jeremy Boynes in the lobby of the W on my way out of town. Jason van Zyl wandered the streets of San Francisco with me in search of a 7-11 and an ATM. Alex Vasseur dropped by the JBoss party to discuss event stream processing. James Strachan and Rob Davis were everywhere, of course.

JBoss

Did some podcast recording with Tom Baeyens, Emmanuel Bernard, Bill Burke and Gavin King. Chatted with Thomas Diesler, Michael Yuan, Matt Quinlan, and Sacha Labourey. Enjoyed dinner with James Cobb, Mark Newton and Bela Ban. Damon Sicore, my predecessor, dropped by the JBoss party. Met innumerable coworkers whos names all fail me during my stints in or near the JBoss booth.

The fabulous Cindy Scheneck, Rebecca Goldstein and Chantal Yang arranged the booth, the party, the printing of the t-shirts and everything else that made it all awesome. Mad props to that trio, Burr Sutter, and the gaggle of sales-engineers who did an awesome job with the attendees.

Observations

With the large investment announced by Interface21, a lot of side-line analysis of business models was happening. Exactly where is the sweet spot of professional opensource? Is it training? Certifying a stack that you control? Supporting a stack that you don’t? Purely professional services?

At the booth, technical demos seemed well received. A large screen and a good sound-system were definitely a wise investment. Every demo drew a large crowd around the booth. A lucky few got to see Gavin debug a demo live on stage. Seam is definitely hot this year.

Luckier still are those who “received” a “free” copy of Michael Yuan’s book about Seam. Did I mention Seam is apparently hot?

We all need to realize that parties can occur on nights other than Wednesday. Luckily the JBoss->Eclipse->Google triathlon worked out, but many parties were concurrently scheduled.

I heard a lot of positive feedback from people I met about liking what we’re doing at JBoss.org. They like the new look and layout. When it’s common for people to throw around criticism and negativity, it’s really nice to hear kind words. Sure, we’ve still got a long way to go, I’ll readily admit, but I think we’re doing a-okay.

In general, conferences like these are somewhat educational, definition inspirational, and help cement human-to-human relationships. While we all might be competitors, we’re not enemies. In the world of opensource, we share the same community, so we all might as well get along and order another round of beers. Conferences demonstrate these cross-cutting commonalities that crosses P&L statements.

Some of my colleagues have put together a page detailing JBoss’s participation at the conference.

Speakers from JBoss include Gavin King and Emmanuel Bernard, Michael Yuan, Tom Baeyens and many others.

I’ll be hanging out at Booth #1418 along with James and Mark from my team. We’ll also be wandering the halls talking to anyone who looks like they need some opensource Java love.

Wednesday night, there’s going to be a party at the Metreon. You’ll need to go register.

The team that pulled this together includes Adam Warski, Tomek Szymanski, Rysiek Kozmik, Przemek Dej, Pawel Wrzeszcz, Mark Newton, James Cobb and Meriah Garrett. Assists from the guys on the Portal team, including the estimable Julien Viet. Last minute assists from Eric Brown and Tom Benninger were also crucial. The whole process was kicked off by my predecessor Damon Sicore.

The guys in Poland developed their fingers down to nubs, particularly crunching out much-needed code towards the end (releases never go smoothly, of course). Mark created the voice and narrative that guides you through the site. James worried over every image, border, font, pixel-perfect placement and navigation flow late into many nights. Plus, an appropriate amount of snark was tossed around with aplomb.

I’m extremely proud of the team for pulling it all together and getting it out the door.

But the journey is not over. Not at all.

While this may seem like a big-bang release, it is actually the start of an iterative phase with shorter release cycles to promote continuous improvement.

With this personality adjustment also comes the freer hand provided by the new enterprise product vs community product strategy. The commercial side of the house will cherry-pick and refine versions from the “pure” opensource community releases of the projects. We’ll keep adding features and functionality, mashing up fun web2.0 things, and generally making JBoss.ORG a robust community for opensource projects.

The future starts now.

You also end up at labs.jboss.com even though you typed jboss.org into your browser. Quite odd.

No really, we are kinda sorta separate from the mothership.

To help differentiate between the two, and try to cement a true mentality of community advocacy, we’ll soon be rolling out a new look-and-feel, along with a reorganization of the jboss.org site. This will actually be a multi-step process, which has already begun with JIRA.

The changes for what we’re calling “.ORG 2.0″ are not strictly superficial. Navigation and organization across the board will be much improved, along with a customizable user dashboard.

Additionally, James and his team will be available to projects for doing design work. They’ll also be putting together a style guide with HTML/CSS snippets to make it easier for color-blind geeks with no design sense (that includes me) to put together a nice looking app. They aren’t here just to make the jboss.org site itself pretty.

There’s activity related to these communities that .ORG needs to support. We’ll be making it easier for these friendly community projects to have a home and promote themselves. We’ll be offering our services to the core projects to seed some of these community projects. We need some Portlets and JSF components, too. We try to eat our own dogfood where appropriate. And sometimes we just like having fun (I’ve got a Portlet driver for JRuby lingering on my hard-drive, for example).

A lot of these projects are ripe for external contributions around the edges. Fostering these small, independent extensions to our core products is crucial. So we’ll be building out more of the infrastructure/forge side, to give these projects homes and visibility. And we’ll be helping with the human interactions to build communities.

You can measure downloads (accounting for spiders, bots and attacks), site visits, RSS subscriptions, site registrations, forum posts. All sorts of things.

You can measure how many issues are opening in JIRA versus those that were closed in the last week. Or the average lifespan of an issue.

We’ll be working with the Release Engineering group to straighten out the download repositories and make it easy for projects to deploy nightlies, snapshots and official releases into repositories we can accurately measure.

We’re going to be looking at providing more robust web stats.

In general, metrics are desired by all stakeholders, both commercial (marketing and PR) and the community (how healthy and active is this project)?

Sorry, no fancy visual aids for this one.

And we don’t necessarily promote them on JBoss.ORG very well yet.

We need to start pointing out to our community when others in the community are speaking.

Del.icio.us can help.

Every day, JBoss developers and community members surf the interwebs. We see things of interest related to our projects.

Now, we just need to tag them as we see them.

Now, we trust Adam, Mark and James. We don’t necessarily trust Larry and Moe or the rest of the world. So we get back to our fancy RSS aggregating, and moderate folks we don’t trust, and auto-approve those we do. Ultimately, we end up with a “sightings” page back at the project’s JBoss.ORG page.

A del.icio.us feed is normally fairly barren, including just a link and a title. Very few folks use the description field. So, we’ll try to annotate links with an abstract or comment, to add some value. Might also be cool to inject a thumbnail snapshot of the tagged site, to help preview what it points to.

We’ll be coming up with a psuedo-structured tagging system for developers and community members to use, along with the underlying software to drive the aggregation.

• Easy-to-use for developers & community members
• Freakin’ pretty to look at
• Browsable through a portlet on jboss.org
• Versioned (just like the code it matches)
• Multiple formats (HTML, PDF)
• Multiple languages

We’re not sure what form this will all take, but it’s the goal.

We have the Red Hat Content Services team available to us, to do localizations. That gives us the possibility of proof-read documentation in 7 languages. Not too shabby.

Of course, their tooling works with DocBook. Some projects certainly might be happy with DocBook, but those preferring the wiki for documentation authoring, the .ORG team will bridge the gap with the Content Services team.

Wikis many times turn into a morass of muck. Mark and I will concentrate on organizing, grooming and helping to write the docs for the .ORG projects. Good docs promote good community.

Ultimately, software to allow humans to blog isn’t overly interesting, until you get to the point of wacky plugins and skins and other frills folks have come to expect.

Additionally, folks have a certain mindset when they write on the corporate JBoss blog, which is different from when writing on their own blog. I think personal blogging, even on corporate topics, tends to be more real and honest. These “off-shore” outposts also help increase the organization’s footprint on the interwebs.

Given all of that…

JBoss developers who want to blog, I highly recommend blogspot.com, typepad.com or wordpress.com. I just ask that you use tagging or categories to allow fine-grained aggregation of your JBoss-related content.

The blogging effort within JBoss.ORG is being re-doubled to focus on fancy twiddling of RSS nine ways to Sunday.

We’re not simply talking about normal aggregation, oh no. We’re talking fancy.

First, lots of other tools produce RSS, including JIRA and Fisheye. Each project’s presence on JBoss.ORG will start being a nexus for this implicit RSS that’s being thrown around. Add a dollop of styling and some RSS portlets, and projects can easily display issues-remaining for the next release, follow changes by developers or on branches, or all sorts of things. We like information overload.

Also, we have content in the wiki and in the forums. Perhaps an RSS feed of an entire forum would be overwhelming. The intersection of the forum feed and a tag feed, though, provides a nicely filtered view of the forum. Developers will be able to tag forum posts as “blogworthy” and magically have a blog produced from their posting.

We have a content team (hi Mark) that needs a way to watch and respond to a lot of what goes on in the community. Developers answer a forum question that obviously should be in the FAQ, they tag it and move on with their life. We can watch the tags, read the forum, and extract a FAQ.

Information is everywhere. And this information represents contributions, in one way or another, by our community. RSS thankfully is a great way to work with diverse information in a consistent way.

And when I say RSS, I probably mean Atom, honestly.

• Blogging & RSS
• Content & Documentation
• Community Noise
• Metrics & Such
• Community Growth
  
• Visual Design

• myspace.com/codehaus
• myspace.com/jboss_org

And don’t act like you don’t have a MySpace account. You know you do.

• JBoss.ORG
• SugarForge
• OpenLaszlo
• MySQL.org

Others are non-profit, or not tightly tied to a corporation:

• Apache Software Foundation
• Codehaus Foundation
• OpenQA

None of these should be confused with .nets, such as SourceForge.net or java.net. The .nets of the world are more like warehouses than communities. Both types of .orgs do share a lot in common, but they also have some functional differences. Working with both the Codehaus (just a community) and JBoss.ORG (a .org sibling of a related .com) is interesting.

Non-commercial .orgs

The non-commercial communities serve both the community members and the actual project developers. The role towards the community is fairly passive, mostly providing the capabilities for participation, contribution and interaction. For the developers, primarily normal “forge” tooling is needed. Here, different communities might select different tools, but ultimately the feature-set is roughly the same.

Ultimately, taken all together, we’re only talking about Subversion, mailing lists or forums, IRC/Jabber, bug tracking, continuous integration, wiki, webspace, and maybe blogs. That sort of thing. Of course managing a bag of disparate tools in a useful manner is no trivial task.


While non-commercial .orgs also may encourage interaction and cross-pollination between projects, it is not necessarily their primary mandate. At the Codehaus, I do attempt to introduce various project leads I think might have a chance at some cooperation, but beyond that, nothing is explicit. The Codehaus is the land of containers, for instance, which might never have any reason to cooperate or share community members.

Apache, on the other hand, does try harder for inter-project cooperation. Projects are encouraged to use other Apache projects where possible and contribute to things such as the various “commons” projects.

OpenQA, through its focus on a particular type of project, also promotes natural cross-pollination amongst the members of each project. QA folks can be… intense.

Commercial .orgs

Commercial .orgs likewise have to address both the community members and the project developers. The project developers still demand good forge tooling, of course. But the .org starts to play a larger role in regards to the membership of the community. Instead of simply facilitating interactions, the .org must also act as an advocate for all users, including those from which the corporation derives no revenue.



With a commercial .org, there are natural inclinations to attempt to directly monetize as much of the community as possible. It’s not at all a malicious goal, since ultimately, the company should try to monetize the community. That’s the whole point. We need to learn that direct monetization is counter-productive, though. Attempts at direct monetization may include putting some content behind locked doors, running banner advertising everywhere for the corporate offerings, or being closed to complementary or competing ideas and individuals.

If everywhere a member looks, they see marketing and sales of the host company trying to grab their attention, it stifles the sense of openness. The revolution will not be sponsored by a single company. In a real community, a truly thriving community, there will be other actors out there in the field. Your projects are hopefully so successful that other people see ways to build their own businesses around them. These folks can be seen as either threats or opportunities. Using the .org only as an extension of your own marketing department would ignore these folks, turning them into threats.

Projects within a commercially-backed .org tend to have more product management behind them, explicitly providing a multiple-point solution across the entire platform of projects. The .org’s role likewise must ensure that the shared communities between projects are helped to find their own commonalities.

Additionally, in the wild world of opensource, a lot of projects just simply fail to develop a community. A commercially-backed project has already shown to have a community, and the company has a vested interest in ensuring that it continues to grow.

The .org plays the role of the park ranger, tending to and actively promoting the healthy land & wildlife of the project. In the “real world”, lightening strikes a dry pine, and 3 million acres of project go up in smoke. A company can’t afford to have that happen.

Pardon the bad analogy.

]]> http://www.fnokd.com/2007/03/15/the-role-of-a-org/feed/ 2 http://www.fnokd.com/2007/03/13/parasitic-community-growth/ http://www.fnokd.com/2007/03/13/parasitic-community-growth/#comments Tue, 13 Mar 2007 20:25:44 +0000 Bob McWhirter http://www.fnokd.com/2007/03/13/parasitic-community-growth/ Sure, you see the word “parasitic” and the first thing that pops to mind is probably “ewww.”

But parasitic behavior is actually a good strategy for new communities, as long as they don’t ultimately kill their host.

Last night Rysiek pinged me about some thoughts on how to improve JBoss Portal, by allowing the core team to work on the core portal, and perhaps have another team that focuses on just writing portlets. He pointed me to a nice wishlist of portlets that would be great to have.

We could certainly put some labor into it, but that wouldn’t help leverage our community.

He and I conversationally strolled around the problem for a while, and came up with some conclusions.

Complimentary instead of stand-alone

It’s hard enough getting someone to build some software you want. Finding a guy who wants to build it, and build it as a portlet is even harder. Instead, perhaps take a strategy of “portalizing” existing non-portal applications.

The thing is it’s hard to start a community from scratch with a brand new project. You might have a large potential community, but you initially have 0 adopters and no easy way to convince people to try your stuff.

If you create complimentary projects that add value to an existing community, the road is much easier. These folks are easier to find and more receptive, since you’ve come to them with a solution that fits their current environment, instead of convincing them your project solves a problem they didn’t even know they had.

For example, everyone loves the various JIRA macros in Confluence. That’s somewhat portlet-like. In fact, JBoss could easily write a few portlets against the JIRA API.

Glom onto an existing community

Now, we don’t have to build a community from scratch. We can find the JIRA community pretty easily. Some subset of that community probably uses some portal somewhere and might enjoy a good JIRA portlet. I’m sure only a subset of those portal people use JBoss Portal at this point, though.

So, we make sure our JIRA portlets are easy to use and are compatible with all portals out there, not just JBoss. This broadens our own potential community, for one. And secondly, it actually creates pressure for eXo, Liferay, and other portals to not create their own JIRA portlets.

Plant some seeds

Now, if we throw out a small handful of JIRA portlets, let’s say, which solve some of the hard problems (like the JIRA SOAP interface being “interesting” at times) and provide examples, we’ve made it easy for the community (the JIRA+Any-Java-Portal subset) to extend our initial seed. And a portlet-creating community grows.

After a suitable amount of time and effort giving to their community, they’ll eventually turn around and give back.

Marketplaces & Communities

Rysiek pointed out the existing JBoss Portlet Swap, which has quite a few things in it. But he comments that the associated forums are almost dead. JBoss Portal Swap is a marketplace where the cost of transactions is zero.

I’m not surprised, given the nature of the Portlet Swap. The actual distributables in it are quite diverse, with a single thing in common: they’re portlets. The stronger side of each of these projects is the non-portlet value-add. Most of the conversation there will occur within the primary community (for example, JIRA’s community, Pentaho’s community). Else, they are simple and not necessarily community-invoking (for example, the calculator portlet, or the flash portlet).

Portlet Swap (and really any marketplace type of thing) has such diversity in its members, it probably won’t have much of a community. It’s ultimately infrastructure. As humans, we might all shop at the same mall. But I probably don’t want to have a beer with you just because we’ve walked the same hallways and shopped at Sears.

Applicable to other realms

I’ve spoken in the specifics of portals, portlets and JBoss’s Portlet Swap marketplace. But this can all be generalized to any project that’s extensible.

ESBs come to mind initially. It’s definition is that it’s a core with a bajillion ways to interface with a bajillion different systems. No way the core team can implement them all. But by providing a reasonable starting point, the community is encouraged to contribute their adapters for their own weird little system. You solve most of their problem (by providing JMS connectors or whatnot), and they fill in the gap with their odd PDP-10 message-queue connector. The ESB project benefits from the nutball PDP-10 community.

Ultimately, by finding an existing community you can compliment and attach to, the easier it will be to reach your prospects and have them contribute back. You can plant some seed and provide some initial value to a group that’s paying attention. With enough care and sunlight, you’ll accomplish what you’re trying to do.

]]> http://www.fnokd.com/2007/03/13/parasitic-community-growth/feed/ 4