Tom Baeyens has written a nice blog introduction to a technical article on the Process Virtual Machine.

Tom's blog is great, because it gives you an understanding of the problems and commonalities between various process/workflow/orchestration technologies. I faffed about with Werkflow though a few revisions, all failing miserably.

I think workflow (and rules) will ultimately be important programming models in the future. While developers may find it hard to transition from imperative to declarative thinking, both of these technologies map more closely to how Real Humans tend to think about problems. This is evidenced by the "flow charts" that match the shape of a business process. We're better at drawing pictures than describing with words the steps involved in taking a thing through a process.

While you sit down to enjoy that turkey or tofurkey sandwich at your desk, perhaps you could surf over to JBoss.ORG and marvel at the new design, organization and layout.

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.

Today, my Canadian friend Jason van Zyl announced his new company based around all things maven.

Jason, as you may know, is the founder of both Maven and the first maven-centric company, Mergere. For some history, Mergere was a child of Simula Labs. Simula started life as a VC-ish incubator, but now seems to be some sort of opensource delivery plumbing, particularly after selling LogicBlaze off to IONA last week.

After his stint in LA, Jason returned to his Canadian motherland and enjoyed a brief respite before launching Sonatype today.

He says he's happy to have Sonatype be classified as a training company, but ultimately he's building out a vast partners network to help make maven pervasive. While they are working on projects with some top-shelf clients, they generally prefer to find partners to provide professional services.

I think this open attitude and approach towards other commercial interests within the maven project ecosystem is absolutely correct. Jason is ultimately the outbreak monkey for maven, and how he deals with his community will make or break any commercial effort. As the entire market for maven-related stuff grows, it will require many players to thrive, not just a single dominant controlling organization. I think Sonatype is heading down the right path by becoming a natural commercial nexus instead of attempting to become a 10,000 lbs gorilla.

Disclosure: Jason's a good friend and co-founder of the Codehaus, so I'm not unbiased.

JBoss.ORG represents the opensource side of the house. Though, for some reason, we look just like the commercial side of the house.

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.

If you don't measure, you can't tell if you're doing things right or wrong.

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.

Tomek and Mark are working together to figure out our wiki/CMS strategy. Ultimately, we have the use-cases of

• 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.

There's people out there talking about us and our projects. They're blogging. They're writing articles. They're speaking at conferences.

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.

As noted previously, many of our projects are capable of sustaining a vibrant sub-community. This includes portlets, ESB connectors, side-projects like Drools.NET, things to jack into JCA, or even our growing collection of JSF things.

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.

To say that "blogging" at JBoss has been contentious would be an understatement. There's currently two different places/ways of blogging at JBoss. And one of them allows blog posts to go missing without a trace. (Thanks Blojsom!)

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.

Just got back from Vegas, where I participated on a panel about opensource and business at TheServerSide Java Symposium. It involved five of us from businesses that were related to opensource in some form. It did not include Geir Magnusson, who apparently had better things to do.

• Alfresco, John Newton
• JBoss, some guy with a beard and sandals
• SpikeSource, Joaquin Ruiz
• Interface21, Neelan Choksi
• Liferay, Brian Kim

Questions that Joe Ottinger and the audience threw at us ran the gamut from business strategy to licensing minutia. On the topic of how each contributes back to the community, JBoss, Interface21, and Liferay obviously employ developers, while SpikeSource primarily upstreams improvements, since they are basically just expert community members.

I think an audience member brought up the idea of the company "holding documentation hostage" for paying customers. Most everyone agreed that ultimately it depends on what you view your business as. If a company holds its docs hostage, someone else will ultimately create some competing docs. It might be the community. It could be a book publisher, who is an expert in creating fantastic docs and holding them hostage until you pay the cover price. That's how O'Reilly, APress, Manning and other companies participate in opensource.

One audience question involved how to define success in an opensource company. Once again, we all seemed to violently agree that success is defined just as for any other company. Profit! It's a dirty but true secret. Companies try to make profits. Opensource is just a method of software development, not a complete business model.

The issue of trademarks did arise. I'm not going to poke the bear here, but company counsel has replied on some of the other blogs out there.

On a different note, I finally got to meet Hani Suleiman, Ross Mason and Mike Cannon-Brookes in person. I ran into Dan Diephouse, Dion Almaer, Jonas Bon and Geert Bevin again.

Only lost $90 on the slots between me and my wife.