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.

Henri Yanell made some comments on my previous post. I interpreted them to mean something like the following:

Within a project's community, one or more companies may spring forth from the project. They share the same community and prospects, and their customers may overlap. (Overlapping customers not shown).

Additionally. within a thriving community exists other providers, perhaps not even directly tied to the project, yet participating in its community.

Of course, depending on the magnification of your view into any community, individuals can be playing different roles. While a project has a community of users, the project itself may participate in the community of the specification it implements. Tomcat and Jetty are both participants in the greater Java Servlet specification community, as are their own users. But within the scope of the individual projects, their communities are distinct.

This is where being "technology agnostic" pays off. By not explicitly aligning with a subset of a larger community, the size of your prospects stays larger.

I don't think I'll even try to drawn a comprehensive diagram of overlapping subsets, such as "Portlet Vendors specializing in AS/400 portlets". I'll leave that to John Venn.

First, there was the project.

The project was created by some guy, in some spare bedroom, at some hour in the dark of night, in some town. He may have done it out of academic interest. Or maybe it solved some problem for him. Ultimately, others shared the same interest or problem, and the project found prospective users. The project only touched the prospects a few at a time, since the project is ultimately small in the scale of the world.

Some of these prospects gave consideration to the project. Some deemed it worthy. Some did not. Those who appreciated it became its community. The community amplifies the influence of the project. Through the community, more prospects are interacted with. And interaction helps to move prospects into the community. It broadens the event horizon between the project and the prospects.

For any group of users, a certain percentage will desire hand-holding, support and additional services. At first, the community is small and the percentage of potential customers in reality turns out to be less than one real human. The community must grow to make any advanced customer relationships viable to the provider.

After natural community growth, the activation energy required to make a commercial open-source offering is met. Enough potential customers exist to cover the risk of dedicating oneself to a commercial offering.

In each case, new sub-groups bubble-up from within existing groups. Community bubbles from the prospects. Customers bubble from the community. And it all ultimately bubbles from the origins of the project.

If you're running a commercial open-source business, you need to acknowledge that the size of the community will and should always be larger than the size of your customer base. Growing a community ultimately bubbles more customers. And future customers, by way of the community, is what leads to bottom-line growth ultimately.

Communities exist independent of any actual connections between people. There's a community of people who have all bungee-jumped off the same bridge as you, even if you've never met them.

But, throw a Bridge Day, and the community becomes visible.

With online communities, this is quite evident. Some communities are purely based around the tools that support them, but many communities have no centralized place to congregate in the virtual world.

The community is happening everywhere. And luckily we have this whole web 2.0 thing happening now, with mashups and remixes. Fantastic.

Mashups allow us to go find the community, where ever it may be, and make it visible and apparent. With appropriate use of RSS, del.icio.us, Flickr or other services, the implicit community occurring across the net gets to have a virtual Bridge Day.