For the last seven weeks we have been working on some significant upgrades to our architecture and packaging.    During this time, we have also been tracking work to fix bugs and irritating behavior in the existing features.  I wondered why we couldn't close this list and move on, and I discovered, under the seven open issues, that we had more than 200 closed tickets.

It reminds me of the circus act where a small car drives into the ring, and 18 clowns get out.  They just keep coming out.  In this case, 200 clowns came out. 

This is a typical dynamic as systems get larger and have more function points.  Fortunately, we don't specify a fixed set of tasks when we begin our iterations.  We keep adding items and fixing them until it is time to stabilize for a release.  I know that many of our customers do like to have a fixed plan for their iteration, and I wonder how they handle the need for taking care of these clowns, every week.

This week, Bill Warner took on the issue of starting and building "Grand Slam" technology companies here in the great state of Massachusetts, with a scorecard and a playbook.  Scott Kirstner covered the scorecard: you get a single when you can hire a few employees, a double when sales go over $10M, and a grand slam if you get to a $10B market cap.  For those of you who aren't Boston insiders, I'll cover the basics of the plot.  Bill remembers the time when companies like Digital Equipment Corporation started here, employed tens of thousands in the state, and made Route 128 a hub to rival Silicon Valley. That trend peaked in about 1980, about the time that Apple and Microsoft were building much smaller offices on the West coast. That year began a long slow decline relative to California.  So, my state finds itself with the same question that thousands of regional economic development authorities are asking - how to grow the tech economy? - but a deeper bench of experienced talent to debate the point.

By 2010, the Silicon Valley tech scene in California is at least five times as big as the one in Massachusetts.  Boston investors and businessmen attached themselves to a shrinking sector, funding enterprise technology and "proven" teams rather than new consumer-oriented products and services.  Young, un-proven entrepreneurs still go to school in Boston, but they are forced to go to California if they want access to funding - Facebook being one well-known example out of many.  Successful Massachusetts technology companies have been acquired by out of state buyers, and few big ones remain standing.

It's the last point that Warner fastened on.  He thinks that the state needs to grow some new big, independent companies, in order to provide opportunity for its tech citizens.  This is interesting, because for as long as I have known him, Bill has been a dogged supporter of small, early stage companies, and he once said about himself (founder of Avid, quite a big company) that he starts to "get uncomfortable after about 20 employees". So, why is he concerned about later stage growth?

He is right.  I believe that having big, successful, locally owned companies is important, for one specific reason.  Those companies buy smaller companies.  Massachusetts doesn't have many big acquirors.  Warner lists three in the Grand Slam category - EMC, Thermo Fischer, and Raytheon, and Kirstner rounds it out with two biotech companies - Genzyme and Biogen Idec.  California has dozens. 

I think that accounts for most of the difference in the startup climate.  The money that Silicon Valley successes pour into acquisitions - many of them local - is what feeds investment of time and money and excitement all the way down to the seed stage.  If Massachusetts has timid investors (indubitably true, relative to California), it is because it's harder for them to make money.  MA investors and entrepreneurs basically come from the same population as CA investors and entrepreneurs, and they move back and forth.  Shoveling a bit of snow isn't enough to stymie their animal spirits.  They clearly face differing reward structures  And, my bet is that local acquirors make it a lot easier to get rewarded.

Ironically, Warner's pitch is designed to persuade companies NOT to be acquired.  I think its consistent.  If you have active local acquirors, that gives you the confidence to make investments, and ultimately makes it more likely that you can succeed independently.

ONE, do I think that it's important to build locally?  Emotionally and intellectually, it would be great fun to live in a hot tech city, and it would provide better opportunities for my friends and neighbors.  I wrote an intensely felt paper on this subject two years ago, and decided against posting it.

But, this feeling is hard to justify from a business point of view.  What we are actually doing as a business is spreading out - building up in California, and internationalizing our our product and our team.  Only 30% of our users are in the US.  When you see the building booms in Bangalore and Shanghai, you quickly realize that the real action has moved far beyond Silicon Valley.

Those locations have faster growth, available labor, and more saved capital - key ingredients for business expansion.  They have a lot more IPO's than the US.  In comparison, it may be even be economically impractical to fight the pressure AGAINST tech growth in Massachusetts, pressure created by the scarcity of affordable housing, the relatively higher salaries in the financial services industry, and government industrial subsidies for housing, banking, education, health care, and biotech (but not software).  All of these things crowd out software jobs.  As in Avatar, "you can't pour water into a full cup." 

With each new hire that I make, I'm finding that the hire is not in Massachusetts.  We hired net 10 people in 2009 (with a lot more coming in 2010), but we only hired one in Massachusetts, even though we did look here.  Maybe I'll write later on the difficulties of hiring in MA.

And, morally, should we be hiring in Massachusetts?  American policy has turned against immigration.  Immigrants create jobs.  I'm not sure we deserve those jobs if we turn away the deserving.

And, in the modern economy, is it important to have LOCAL acquirors?  Bill has making that case, but I think we might be entering a new era.  Any acquiror's money can flow through to new ventures.  My theory is that we can pump up the startup economy by having acquirors regularly visiting the area and thinking about strategic acquisitions.  My regional development idea is just to set up a bigger, more persistent version of the yCombinator / Techstars investor demo days, where investors get opportunities to see the local merchandise.

TWO, are there behaviors that we can engage in as business people and regional citizens - the Warner playbook - that make it more likely we can have big successes?  I don't see much in this list that people don't already aspire to, or get as advice every day.  There isn't much that would qualify as a new behavior.  These proposals are, in essence, New Year's promises to "be better at business".  They are at the same level as trying to lose weight by promising not to eat dessert for a year.  We know how that works out.  I think my idea for a regular program to bring in acquirors and connect them with local startups is new, more practical, and will do more in reality.

I'll comment on the three proposals that I think might actually be a little different:

Awesome Angels) Angel investors are incredibly brave, because later stage investors are dedicated to pushing them out of the deal, and their stakes are exposed, and often don't survive to exit.  If we could change this dynamic (deeply rooted in Boston) we would unlock a lot more angel investment.

New blood) Bill mentions the need to recruit from California, but what about from outside the US?

THREE, do I think it is important to aim high and build big and not sell out before you do what you can do?  Yes, I do.  That idea holds true wherever you live.  Enough of that thinking, by enough lucky and smart people, would at least satisfy Warner's goal of building some headquarters operations here in Massachusetts. And, it makes a difference for society.

But, my actions don't necessarily show me supporting this position.  Assembla is small, mostly self-funded, and very capital efficient.  Our customers and our partners tend to be the same way.  We're a product of the new reality of global competition, which pushes us to Japanese levels of process efficiency, and Chinese levels of cost.  We're also facing the cash flow reality of software as a service businesses, which get only small up front payments.  By having no fixed costs, we limit our exposure to volatile investment trends.  Under these conditions, we can make a profit, build new products, double revenue once a year, and I can end up owning, actually owning, a profitable business.  That's the old fashioned way to build wealth - much more reliable for the founder than gambling with VC money.  But, it's not the best path to innovation. There is a lot of criticism of the idea of capital efficiency as an enemy of innovation, and I think it's valid.

So, we are well adapted to the current environment.  But, are we doing enough to change the world? We need to improve on that score.  I think a lot about that.  We are planning to use partner resources to do bigger things (yes, those guys are in California).  But, given the terrific underlying fundamentals of our sector (cloud computing, in various forms) maybe we can participate in a regional effort to do more.  I'm in.

We want to get YOU involved in the development of new Assembla.com features with a new bounty development program that offers money (up to $10K per enhancement), glory (your logo, link, and blurb on your feauture), and a chance to get the feature that you want.

Some of my colleaues and customers have thought that I was crazy to open up the code and development process on our commercial product, but now it's clear that you can help us, and we should be even more aggressive about sharing and crowdsourcing.

Read the Assembla Development site for details about our technology and offer.  Read the Project Ideas page for a list of projects that we want to invest in.

Why would you want to do this?

• Bounty payments, up to $10K.  We have a better budget than most open source projects, and we support the idea of paying developers fairly.  Although we are a small, bootstrapped company, this bounty offer is a lot better than many big-brand offers.  We don't force you into a "contest" where you might not get paid.  If you submit a good proposal, we will commit to you as a development partner.
  
  
• Promote yourself. For as long as you maintain the tool, you can add your logo, link, and a line of text on the bottom.
  
  
• Get what you want.  Share your expertise as an Assembla user.  If there is something missing or inconvenient about Assembla.com, you can implement it correctly.
  

Assembla is a relatively complex Ruby on Rails application, so you need to be able to work in that environment.  But, you can build "tools" (additional tabs) without installing the repositories and other external applications, and we even created a script that you can run to generate the skeleton of a new "tool".  We provide documentation to set up a development environment on Linux, Windows, and Mac systems.

Why are we doing this?  Assembla is committed to offering best-of-breed features for ticketing, repositories, and event streams.  We believe that our core team needs to focus on providing these features, at high quality, in a scalable and reliable way.  We can provide other tools with high quality, but only if we outsource development and maintenance of these tools to partners with more specific expertise.

In addition to being a showcase for individual developers, this bounty program is also a good way to work with outsourcing companies.  We frequently get calls from outsourcing companies that respond to our developer job ads,and want to work on some of our Assembla projects.  We don't accept these offers because we have found that it is difficult to qualify top individual developers this way.  However, this bounty program allows you to qualify and manage developers in your own process, and show off your capabilities.

Thanks for your ideas and suggestions.

As some of you know, Assembla publishes its code and development tickets on the Internet.  This makes it easier for us to engage new developers, and it gives our customers a chance to directly follow the development of Assembla.com features.  Now, we are moving our published code and developer instructions to a new location in the Assembla Development workspace.

We have also removed permissions to the old "Breakout" development space, so you you will not be able to see our tickets, discussions, and unreleased code.  Why?  Assembla is in a very competitive category.  We are making a commitment to jump forward with new features and offers.  We can make a bigger investment if we keep these features and offers quiet while we work on them, so that we can gain some competitive advantage.  This is good news for users that depend on us to advance the state of the art.  Look for some significant announcements within the next month.

The weather here must be perfect most of the time, because it seems great
to me, and they are complaining about the heat. It's better than
scraping ice off my car in Boston. I'm getting good ideas from the local
entrepreneurs. One acquaintance told me about a Lego robot competition
he will attend in South Africa, so maybe there is a new tech current
running completely south of the equator.

 --Andy Singleton

Someone needs to monitor the cloud services that we depend on.

At Assembla, we have been building complex systems with cloud servers.  In one recent case, we linked together voice servers, a Web application cluster (Web servers, app servers, database servers, message processors), and a secure credit card processing cage, all in different locations.  The advantages of building a system on cloud services are huge.  Such systems can be developed and scaled with unprecedented speed, and limited capital cost.  However, they are dependent on the reliability of the underlying systems.

As Web users, we expect that servers will be up 24x7x365.  I certainly do.  As vendors, we have to swing into action instantly if there is any downtime.

That is why some of us got up last night to fix a problem with a client's system (not assembla.com).  The network storage devices at one of our cloud hosts had become un-mounted.  We have seen regular slowdowns or outages in this particular storage service.  The Amazon EC2 system that hosts Assembla.com is more stable, but only a week ago we lost a bunch of virtual servers (a condition which Amazon warns us to expect).

We can jump into action with failover systems or workarounds for these problems.  But, being notified about the problems, or likely sources of problems, is critical to both putting in a workaround, and planning failover.  And, in last night's case, the vendor wasn't particularly helpful.  They didn't actually notice that they had a problem with their storage devices until we pointed it out, and they didn't warn us about the outages they would cause while fixing it.

So, someone needs to monitor the cloud services that we depend on.

This monitoring would cover a few needs:
* Customers need to be alerted when there is a problem with the cloud services that they use.
* Customers want historical data to see the maturity and reliability of services they are considering
* Vendors need current quality metrics and trends, alerts, and comparative metrics.

As services mature, monitoring is less critical.  However, hosting companies are constantly adding new services - new types of servers, storage, database, message queues, content distribution, higher level apps, etc., so there are a lot of potential problems to monitor.

Is this service available?  Is anyone interested in going in on a monitoring system for cloud services, a sort of weather report?

At Assembla we manage everything with tickets, so we were very happy to see the new Assembla Tickets iPhone application, from Butterfly Avionics. It gives you the ability to view and edit your tickets on the fly.

This application keeps your work on track.

The application will display the tickets with a nice status indicator on the left hand side.  Select any ticket to get a full-page display, edit, and comment.  Select + on top to add a ticket.

The iPhone application uses the Assembla REST API (link here) .  Get it for $11.99 on the iPhone app store.

Today I saw an interesting article in the Economist about improving online collaboration by moving beyond email.  They mention alternatives like Google wave and Facebook.  I notice that they did NOT mention ways that online collaboration is becoming more like real world meetings, with video conferencing, etc.  Actually, the world is moving in the opposite direction, and making "real world" interactions more like online interactions.

I see the trend when I watch my teenage kids.  They spend a lot of time using Facebook to communicate with their friends, and they spend less time going to see friends then I spent when I was their age. That doesn't mean they do less socializing.  Far from it.  But, in a lot of circumstances, the online version is at least as satisfying.

This doesn't mean that their friendships are "virtual".  Their friends are very real.  I have always avoided using terms like "virtual teams" and "virtual collaboration" to describe working over the Internet.  "Virtual" means "not real", and these distributed teams are very real, and they collaborate in a very real way.

So what is different?  Mostly, it's multitasking and time shifting.  When you use IM / Facebook / Google Wave, and Assembla, you can have multiple conversations running, and come back to them at different times.  There is a place for single-focused, real-time attention.  But, that seems to be a very special place that people go to on special occasions.

These kids will be in the workplace very soon.  As noted in the Economist, their tools are already here, bringing changes.  I won't say that these changes are good or bad, but the trend is clear.  The work team of the future is not going to be like the teams of the past that got together in scheduled, single-task meetings.  And, we are not seeing a mass movement toward video-conferencing and other tools that make distributed teams feel like they are present in meetings.  The work team of the future is going to use online, multi-tasking, time-shifting tools.

Assembla IS the best place to deliver or receive code.  Let me explain why that is important.  Last month I sat across the table from an entrepreneur who could not get his hands on his code.  He was actually in the process of contacting the police to find the developer who had the code and instructions he needed.

Does that sound farfetched?  I have a couple of these conversations every year.  In one case, I was hired to replace a 2 million dollar product that was operational, but missing the source code.  Losing code is a worst case scenario, but most projects suffer from IP loss at some level.  Most of the non-agile projects that we look at have trouble running builds.  They just don't do it that often, and the systems or instructions go out of date.  What percentage of software projects can track down all of their documentation, or have a complete record of the discussion about a particular feature?  Who did what?  Can you shut down, go to a different project, and then come back and pop off a new release?  Most of the people reading this blog have all of their IP online and under control for their own code ... but what about the stuff they entrusted to contractors or outsourcers?

It's easy to keep track of code.  You can export or clone a repository, and take it anywhere.  It's more difficult to transfer all of the other stuff - the build process and build environment, the documentation, the tickets and discussions, the contacts.  If people can lose access to code, then they are even more likely to lose access to the IP that makes it alive and maintainable.

Assembla fixes this problem in two ways.

1) Assembla allows you to transfer ownership of a complete project from one subscriber to another.  So, if a designer starts a project, he can hand it off to a development shop, which can then hand it off to the client.  This is a unique capability in our category.  And, it is important.  If you are a client, you should demand a handoff capability, and if you are service provider, it's a best practice to provide it.

2) Assembla is an integrated and extensible system that captures and holds multiple kinds of IP.  We started with the key elements - a code repository, tickets (tasks and plans) and wiki (documentation of all types).  Now, we are adding support for builds with the FTP tool and Server tool.  Future releases will see us go further into managing virtual server build environments, logging real-time communication, and opening the system up so that users can add their own tabs and tools.  We bring all of this stuff into a deliverable package.  Even if the bundle of stuff in a "space" changes ownership, or gets stopped and restarted, it's still alive and ready to go, without missing links.

We get some pushback from customers that feel more comfortable having projects and users in their own separate walled-off accounts.  We hear you, but we think that the ability to move projects between accounts is important.  There are also other benefits of sharing in a portal environment.  We get questions about extensible spaces and the number of tools.  To make sense of it, we have things like our "Get a Space" catalog, and users have to figure it out.  We need to do extra implementation work too.  But, there is a method to the madness, and a reason we do this work.

Some folks use Assembla because we provide reliable repository hosting with good features. Some folks use Assembla because they want to accelerate the work of agile distributed teams.  Some folks appreciate the extra management features for handling multiple teams and clients.  I am both a buyer and a seller of distributed development services.  What I appreciate about Assembla is the way that it delivers software and the related knowledge in a nice, integrated, portable bundle - no drama required. 

The real IP value is in this bundle.  If you are building software over the Internet, you should deliver it proudly, and if you are buying software over the Internet, you should demand it.