Current Articles | RSS Feed RSS Feed

Surviving and Thriving in the Best of Breed Web

Posted by Andy Singleton on Fri, Oct 17, 2008 @ 03:45 AM
 

About six months ago, we noticed we were getting our butts kicked.  As I talked to leading edge developers, I found that many of them were not using Assembla.  They said they liked Assembla, but they wanted to use some one tool that wasn't on Assembla - a repository, or a messaging system.  They ended up registering every team member for several different services, to get the capabilities they could get from Assembla all in one place.  For them, the single team list and login at Assembla wasn't a benefit.  They were willing to put up with the hassle of multiple accounts and kludgy Web services, because they wanted Best of Breed.

This is a major trend in Internet buying behavior.  It will affect everyone that sells application services.  Read on to find out what we are doing to survive and thrive on the Best of Breed Web.

To see how Best of Breed becomes a powerful driver of buying behavior, consider a situation where a user needs three capabilities - a code repository, a message/discussion system, and a ticketing system.  Imagine  that Assembla provides a capability in each category that is competitive with the best service available anywhere else in the world.  In this scenario, Assembla is awesome.  When comparing Assembla's integrated feature with the best feature available in the world, a user will select Assembla 50% of the time.  Even in this case, the awesome Assembla case, there is only a 12.5% (1/8) chance that Assembla will be preferred in all categories.  87.5% of the time, the user is tempted to go with best of breed

On the Internet, an application that tries to force the user into a complete and isolated solution (as our users suspected Assembla was doing), will only get a small percentage of users.  On the other hand, if an application is clearly best of breed in one category, it can wedge itself into the best of breed bundles for many users, and benefit by getting links from all of the other apps.  You can offer a complete solution - many people will appreciate the convenience - but the first rule is that you need to be best of breed at some one thing.  That one thing is what gets you into a lot of bundles.

We needed to find our entry in the best of breed race. Many of our users come to Assembla for Subversion, and often they come only for Subversion, so in the eyes of the marketplace, that was our best of breed slot.  However, Subversion is a commodity that is available from almost any hosting compay, which sets a very low pricepoint, even for our enhanced version.  We have been working to bring our Tickets tool up to best of breed status.  It's good, useful, popular, improving quickly, and near parity with the best of breed.  We will achieve best of breed with Tickets.  However, it's in a crowded category.  It would be even better to have a high-value, original, unique offering.

After thinking about this for a few weeks, and trying to work with disjointed best of breed bundles selected by clients, we realized that Assembla had a huge new opportunity.  The people who are running their teams with best of breed bundles have created new problems for themselves that need to be filled with new best of breed tools - Team, and Stream.  When we originally wrapped the Assembla application around Trac and Subversion, we solved those problems.

Team: The first problem is simple - keeping the team list.  If we can add team members in one place, and then replicate the team, we prevent problems for new team members, and if we can remove them in one place, we prevent security problems.  So, if we can replicate the team members or permissions from the Assembla team tab, we make life a lot more convenient.

Stream: You want to see what your teammates are doing.  This second problem is more complex, but more important for driving productivity.  I talked about this as Workstreaming.  Workstreaming is like lifestreaming, like a professional version of Twitter of Friendfeed.  However, it's more complicated because the you can't just share your work activity (events) with all of your friends.  The permission to see them is controlled by the project owners.  So these events get organized into permissioned project views like the Trac timeline or the Assembla Stream tab.  If we could gather a wide variety of events into the Stream and Alert system, we could build a powerful view of activity that would unify the team, improve communication, quickly expose and resolve issues, and provide visibility for managers.

So, in this new world, you want to make a list of the apps that your team uses, and have some godlike hub application replicate the permissions and show you everything that team members are doing.  In Assembla, it might work this way:

  1. Create an Assembla space with just the Team and Stream tabs
  2. Select the external applications that we use from the Tool list in the Assembla space.  These tools are "external" tools.
  3. Go to each tool tab, open the settings panel, and put in the information that allows us to connect to our account on the related app: user credentials, API credentials, RSS URL, etc.
  4. Use buttons on the tool page to replicate the team or data, if those operations are supported by the external tool
  5. See everything that your team members are doing in the related applications, run reports to see what happened, register for activity alerts to see what is happening now, and send the activity "events" to any of the related applications.

We went to work building the architecture to make it happen.  We streamlined our tool architecture to make it easier to add external tools, and started working on documentation for a development kit that outside developers can use to add their tools.

If we end up supporting hundreds of tools, then it will be confusing for users to configure them and connect them together into useful combinations.  So, we built a catalog where users can select a preconfigured combination of tools with a single click.

Introducing the Event Hub

Our most radical move was to build a new piece of infrastructure – the Event Hub – to let you see what your team is doing around the net. It collects events (code commits, ticket edits, new messages) from Assembla internal tools and displays them in the Stream and alerts.  It can ALSO capture events from external applications (for example, your external repositories), show them in the Stream and alerts, and ROUTE them to other external applications (in a simple example, Twitter). It’s like a permissioned friendfeed for a working team.

The Event Hub is a major piece of infrastructure for the Best of Breed Web.  It's necessary.  Without the event hub, every application needs to implement many interfaces to other applications, and there are millions of combinations.  For instance, if a repository system wants to post commit events to ticketing systems, it needs to implement a different Web service for each supported ticketing system.  With the event hub, the repository only needs to post commits to one system - the event hub - and from there they can be distributed to any supported ticketing system.

Enterprise - they prefer integrated

I will note that Enterprise buyers will prefer an integrated solution rather than a best of breed bundle.  Inside the corporate firewall, there is not as much choice to put together a bundle.  Enterprise buyers want software that meets a consistent standard of security, compliance, and support, and we've got a great integrated offer for them.

Tags: , , ,

COMMENTS

So whome are you trying to attract exactly? Someone looking for an external host is most likely an OSS developer, like myself. I am not making money from my projects and am not interested in paying anyone for hosting it. If Assembla starts making me pay for my spaces, I'll go someplace else. If there are no ways to host it for free, I'll just keep the projects to myself. The way I see it, the only reason to offer free spaces is if you want to support OSS for some reason, and are able to make money in some other way than getting paid for the actual hosting. Is this your goal? 
 
Now, for an OSS project, the requirements are a bit different from what you outlined above. A repository is the most important requirement. Everything else can be hosted elsewhere, on one of the multitude of free web hosts, but I can't host a repository through a web page! git can technically do it, but it still requires git tools on the server, which ain't gonna happen. 
 
The second requirement is to publish the project's distribution. That usually includes a tarball and a webpage containing documentation. Assembla can do both, but poorly. Yes, there is a files page, but it isn't really designed for distribution. It isn't sorted, for one, so if I update an old tarball, it suddenly becomes the "latest" download. There is also no download count, so I can't see if anyone is actually using it, but this is not essential. The wiki page can be used for project documentation, but the look is rather unprofessional, with all that extra project clutter around it, so I'd host that elsewhere (currently on SourceForge, where you get an actual web page). 
 
Communication is the final requirement. I could, of course, just tell people to email me with bug reports and the like, but it's nice to have a ticket system and a forum. Most OSS projects only have one or two developers, so coordination is really not an issue. The issue is communicating with the users. Assembla does a decent job here. 
 
When all of the above is considered, SourceForge is overall a better place than Assembla. Unfortunately, it is dog slow and can't host a git repository, so I'm here, making do with a hodgepogde of services from here and from there.

posted @ Tuesday, October 28, 2008 11:43 AM by Mike


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: