The Internet is full of comparisons of the relative popularity of web browsers, but something these analyses miss is that "web" traffic is increasingly not about "browsers" at all. As SOAP and SaaS and Clouds expand, the web has largely become the Internet: the backbone for many services not directly displayed to human eyes.

As a case in point, consider our site Tigris.Org. I was analyzing traffic there recently, for other purposes, and came upon some interesting numbers. In a period of a few (basically randomly selected) days recently, 

• Firefox browsers hit the site 2,964,556 times, making them #3
• Internet Explorer browsers hit the site 3,350,885, making them #2 by a fairly narrow margin (13%, which is narrow compared to the 40% or more these numbers change from day to day)

But "who's number one" you ask? Subversion, with 5,724,275. Subversion traffic is roughly equal to Firefox and Internet Explorer combined! 

Chrome (501,455) is doing pretty well, for a newcomer, clocking in around #6, and Safari (302,483) is at #7. 

"Wait," you say: "there's another gap there, what happened to #4 and #5?" Web crawling spiders working for search engines come in at #5 (1,116,299), but what's #4? Java libraries of several sorts (1,798,848).

Sorted out in order:

1. Subversion: 5,724,275
2. Internet Explorer: 3,350,885
3. Firefox: 2,964,556
4. Java: 2,915,147
5. search 'bots: 1,384,917
6. Chrome: 501,455
7. Safari: 302,483

So: version control operations are overwhelmingly number 1: people are using the web to create new stuff.

Browsers are still big business, at #2 and #3 (don't short-sell your Firefox stock just yet ;-), but on the web, "automation" is "Java" is roughly equal to any human browsing.

I spent a great half-day at CloudCamp @ CommunityOne, this week. This was an Unconference, "a facilitated, participant-driven conference centered around a theme or purpose," meaning that the agenda and content were provided by the participants. The format can be very effective, especially in cutting-edge, rapidly evolving areas like this.

Indicative of the state of cloud computing, our first order of business was to hammer out a definition: what is "Cloud Computing"? We quickly agreed that abstraction from hardware management was a key thought, but I don't think anyone really believes that's the whole story. Certainly not this group! As we talked, it became clear that most participants thought Cloud Computing also requires refactoring your application for horizontal scale, statelessness and location transparency, and a few other fairly new programming disciplines. These might be part of the definition, or perhaps just "best practices," but they were high on everyone's interest list. (There is, by the way, some good work on-going at NIST in defining the terms of cloudy discourse.)

What strikes me in all this is that, if you're deploying into a cloud, you're going to need several of 'em. Just as you can't let developers and testers and untried code onto a production system, so also a production cloud needs to stay clean. You may be able to share lower levels, but you'll need security separation, debugging tools, experimental versions, and so on. NIST talks about three "cloud delivery models":

• Cloud Software (Applications) as a Service
• Cloud Platform as a Service
• Cloud Infrastructure as a Service 

This all fits very nicely into CollabNet's Lab Manager component: the Lab Manager can allocate infrastructure instances from several providers, and track the profiles that distinguish production from test, test from development, application from platform, and so on. If you're developing at the Infrastructure level, you can use the Lab Manager to allocate physical boxes in your own office, so you can poke and prod. If you're working at Platform level, you can allocation physical boxes anywhere, and exercise your location transparency in and out of lab, test, and even production. And if you're clouding up your application, you can float blissfully above all that, while still complying automatically with your local policies.

One of our main goals and success factors at CollabNet is to listen carefully to our customers and prospects to understand your specific requirements. These requirements drive the development of new features within our products significantly. 

This blog post is a call for participation with two opportunities - An opportunity for us to listen to your needs, wishes and best practices and an opportunity for you to actively participate in our requirements engineering process.

For a research study focusing on improving the tracker workflow management features of SourceForge Enterprise Edition (SFEE), we developed a survey and a workflow extractor tool  to gather your current tracker workflow configuration and learn more about your needs.

The workflow configuration of a tracker defines its statuses, its permitted transitions between the statuses with their constraints (e. g. required fields and roles for a transition to happen) and its auto-assignment configuration. You can find the current workflow configuration of your trackers within the project admin tab in subsection “Tracker Settings.”

Please take part in our Survey

If you would like to take part in our survey, you can rate five proposed new features that extend the functionality of SFEE's Tracker Workflow Engine. Every feature comes with three examples of how it can be applied to boost the tracker workflow and ticket handling process within your organization.

Of course, you know better what your organization needs than we do, so don't miss the chance to vote for and comment on these new features.

Please share your Tracker Workflow Configuration with us (Free Open Source Tool)

Getting a rating for potential features is one part to improve SFEE - seeing how the current features are actually used is another one. Therefore, we developed an Open Source SFEE workflow extractor tool.

CollabNet's Workflow Extractor Tool will automatically extract the tracker workflow configuration of your system and store it within an XML file. If you send the information within this XML file to CollabNet (please zip it before), it will be used to find out how and how often the various features currently available within the tracker workflow engine are actually used and how they can be improved.

If you like that CollabNet can come up with further ideas of improvements by considering your unique situation, just download  our tracker workflow configuration extractor tool, follow the instructions in the README file and send the resulting (zipped) XML file to CollabNet.

Play around with Free Code Samples

Last but not least, the full source code of the workflow extractor tool and a pre-configured Eclipse project are also part of the download. If you are interested in some free code samples how to retrieve the tracker workflow configuration, the project names, its associated users, releases and tracker names for your whole SFEE site or even multiple sites, feel free to play around with the code. Of course, you are allowed to use some snippets within your own projects.

Thank you for actively shaping the future of SourceForge Enterprise Edition, I promise to keep you updated!