Analysis

Identity Crisis (org, com, labs???)

The first thing that stands out when accessing the current jboss.org site is that the URL in the address bar of the browser never reads http://jboss.org. Instead it reads http://labs.jboss.com/portal/

This immediately raises the following questions?

     Is this jboss.org, I'm sure I typed jboss.org?

     Is it jboss.com, it says jboss.com?

     What is labs, I never heard of that before?

     Why does it say portal, is there another part of the site to see apart from this?

By comparison if you go to apache.org then the URL correctly reads http://apache.org. No confusion.

If we are to ever clearly define what the difference is between jboss.org and jboss.com then I recommend that everything community based in hosted on jboss.org and everything company based in hosted on jboss.com.

If this is not done and the two sites overlap then we will just end up in the position we are now and confusion will reign.

JBoss Labs (and JBoss Forge?)

The second thing I notice is that we include the JBoss Labs project as a project hosted by JBoss Labs. To my mind this is just confusing. I assume that the reason this was done was to encourage a community of developers around the project to help improve it but it seems to detract from the real goal of jboss.org which is to foster community development of the enterprise middleware projects.

The third slide shows how the Contributor Agreement link in the left hand-side navigation panel leads into a set of pages mostly concerning how to use JBoss Labs. There are a couple of links to the 'How to Contribute' and 'Development Guide' pages but these are nothing to do with using JBoss Labs.

To clear up the design I would recommend that we remove JBoss Labs from jboss.org and carry on development internally since it makes the purpose of jboss.org very clear. The value of Red Hat funding the jboss.org site is that it can provide infrastructure and processes (in the form of JBoss Labs) to the hosted projects so that the community can concentrate on innovation and making the best software possible.

Having said this I'm not sure of the community involvement in JBoss Labs and if it is sufficiently large then it may be a bad idea to take it away from the community. Also the idea that the infrastructure of the jboss.org site is itself open source is both novel and appealing. Either way I think there should be a clear delineation between the JBoss Labs project and the other jboss.org projects as they serve two different purposes.

jboss.org --> jboss.com --> jboss.org --> jboss.com

Looking at any of the slides you can see that the user is led from one look and feel to the next almost at random. The second slide shows this the best as it has the most pages.

The visual disconnect here is acute and contributes to the general feeling of confusion.

To resolve this we need to keep the user on one site (jboss.org) and locate the forums and wiki there. Access to the JIRA system may be achieved using web services in which case we can create a GUI layer that conforms to the jboss.org look and feel. Such changes will hopefully lead to a common look and feel across the entire site.

As part of these changes I would like to see all references to jboss com training, consulting and subscription removed from the jboss.org site. A single link at the top of each page to the jboss.com site should be sufficient to let the user know that there is a commercial side to jboss. By keeping the two sites very independent from each other I am of the opinion that it will help to show the value-add that comes from jboss.com.

JEMS Projects, JBoss Projects and Labs Projects

I think James has already covered this but it is not clear right now what the difference is between a JEMS Project, a JBoss Project and a Community Labs Project. On the new site we should just have JBoss Projects which consist of all the current enterprise middleware projects. If we decide to keep JBoss Labs as a project then I would recommend linking to it from a page describing what jboss.org is and not from where the other project links are located (i.e. It is an exception rather than the rule). I'm also not sure if having an incubator section is worthwhile as it too dilutes the message that we are developing established enterprise middleware projects. The reason I push this so hard is that I see JBoss as being different from Apache Software Foundation or Sun Java.NET because we are focussed very clearly on one thing which hopefully allows us to concentrate 100% on successful delivery.

The value of JEMS should be clearly stated on the jboss.com site to show where the value-add comes in. i.e. additional training, consulting and support and JBoss ON.

JBoss Wiki, JBoss Wiki??

Currently we have 2 wikis that are used on jboss.org/com. The reason appears to be because a wiki was needed for the JBoss Labs infrastructure and the existing wiki did not have the required functionality.

The original JBoss Wiki went live on February 27th 2004 and as such contains a lot of useful information. To edit the wiki you have to be registered but there is no way to apply a finer level of security, any registered user can edit any page. Also the wiki does not cater for multiple languages and cannot display images inline. To rectify these problems the JBoss Wiki project was created but the content from the first wiki was never migrated. As a result there is duplicate content and links that cross between the two implementations. Again this is confusing and does not produce a good, consistent user experience.

Additionally some JBoss project leads have asked if the new JBoss Wiki can be improved or replaced as they would like it to look better. One suggestion was to use Media Wiki, the technology behind wikipedia.org. (http://www.mediawiki.org/wiki/MediaWiki)

Sourceforge CVS, Internal CVS, Internal SVN???

The next area that leads to confusion is the location of the JBoss source code. Originally the JBoss project concerned just the application server and it was hosted on Sourceforge using CVS.

A decision was then made to move the codebase to an internal machine called cvs.forge.jboss.com on 20th April 2005. A further transition to use SVN was made on 31st July 2006.

As a result the instructions for locating the source code for the application server can be quite confusing for a new comer since information for all 3 kinds of access can be found on the site.

Most of the references to source code in the wiki also talk about JBoss AS with other projects not being mentioned at all.

Note: The Developer Resources matrix on the Home Page is a good idea in this respect as it allows for quick access with in a few clicks.

Broken links into JIRA

From certain wiki pages it is possible to click on a link to 'Submit a Feature' to JBoss. Clicking on these links however causes an error since the user has not been able to choose a project. Experiences like this do not give a good impression and raise the barrier to entry for someone wishing to make a contribution.

JBoss AS --> JBoss Cache, JBoss Transactions, JBoss Messaging

In terms of contributing to JBoss the definition of what you are contributing to has changed over the years. Originally you literally contributed to JBoss as this was the name of the application server project. However JBoss is now used as an umbrella term to describe any of a number of related enterprise middleware projects, one of which is the application server JBoss AS.

The pages that describe contribution should therefore reflect this change and emphasize that you are contributing to a JBoss project. They should also emphasize that you can contribute in different ways. You may be contributing feature code, bug fixes, performance improvements, tests or maybe documentation, tutorials and graphics. It could be possible that you wish to contribute your spare time to meet other JBoss users in a user group or hold a talk on a topic of interest in your area. These kinds of contribution should all be welcome and the means with which to make them happen should be as simple and concise as possible.

Summary

JBoss.ORG (Helping the open source community to develop Java Enterprise Middleware)

The current jboss.org website is not clearly designed when it comes to helping users make contributions. It appears to have evolved over the years in an organic way with certain events such as the introduction of the first wiki and the introduction of JBoss Labs causing a couple of major shifts in look and feel, structure and content.

I would like the redesign effort to concentrate on giving the new jboss.org site a clear focus. This focus is helping the community to develop each of the JBoss Projects. Instead of describing how to use tools externally to the site I would like the user to use tools directly from the site. For example instead of going to jira.jboss.com the user could submit a new bug directly from a portlet on the relevant JBoss Project page. This may be achieved using web services although more work is required to see if this is implementable.

The jboss.org site should be as much about writing as reading. Contributing changes back should feel simple and natural. If we could record each contribution that a user makes then we could even summarise their efforts over a period of time so that they can demonstrate to others how much effort they have contributed. This could be useful for a CV or to demonstrate commitment to open source when joining another project. It would also allow Red Hat to track potential future employees by seeing who contributes the most.

The goal of the site would be to enable the development of the highest quality and most innovative java enterprise middleware possible using the open source methodology. The jboss.org site would cater for individuals needs and desires to create a community regardless of company affiliation and to make it distinct from the jboss.com site which would cater for companies needs and desires.