Jon Udell: Hi, this is Jon Udell. Today's Friday podcast is a conversation with Andy Singleton. I've known Andy for a long time. We brought him in a couple of years ago on an InfoWorld story about outsourcing to discuss the approach he'd been taking to the dynamic assembly of global teams. More recently, he's put together an application called Breakout, at his site Assembla.com, in order to try to commercialize and scale out that approach -- and that's what we got together to talk about today.
Andy Singleton: What I do is I practice what I call "inspired by open source" software development. So I put together distributed teams, and I try to work with the best people available in the world for any given job. And what we're trying to do with Assembla.com and the Breakout application is equip those teams, and make it possible to do that kind of work in higher volume, and make it possible for other people to do it. What I found was that I was using a lot of different kinds of online services, advertising services, and applications to piece together these teams. It's something that I could do, but I couldn't explain it to someone else. So we're in the process of breaking that down, integrating it all into one place, and essentially turning it into a wizard. So that if you want to build one of these teams for commercial use, mostly, but also for open source use, you can.
Jon: So you're trying to scale out the skill set, basically, that you've cooked up for your own purposes. Let's back up a little bit. Let's see, it's been what, a couple of years now, since we collaborated on that InfoWorld story about outsourcing?
Andy: Almost three years, yeah.
Jon: That was early on in your career of being someone who's got a hand in a whole bunch of virtual companies, which are affiliations amongst sets of open source developers around the world, and clusters of open source componentry that are brought together, typically short-term, in a pretty focused way, to solve a particular problem. Is that an accurate description?
Andy: Yes, it is. I work with start-up companies that need to put together development teams quickly. So the short-term aspect of it is the way that we put these teams together. It takes less than four weeks to assemble a team, and I've been doing that, I've done that now for a number of start-up companies. I would hesitate to call them virtual companies or virtual teams. They're distributed, but they're very real teams, and that's the idea. In fact, the company that we talked about in the InfoWorld article on dynamic development, which is what you dubbed it, was BioEra, and they've been working together with some of the guys that we put together for three years.
I'm now deploying Breakout, the distributed team application, for BioEra. One of the things they're thinking about doing with it is organizing the global response to the Avian Flu epidemic. When you start to think about how people can organize themselves into small teams or very large groups, you start to look to open source techniques, and how people are working together on the internet, and you find a lot of ways to apply that. BioEra is in the forefront of doing things that way.
Jon: I mentioned to you yesterday Yochai Benkler, who's written a book called the Wealth of Networks that everyone keeps mistaking for The Wealth of Nations. The thing that struck me most was his notion of how the capacity for loose coupling in the human domain, for transient affiliation...
Andy: ...well, I call that "on-demand team."
Jon: Yeah, anyway, that it's a profoundly new economic force in the world. He says that in the past, to create a collaborative working environment, there had to be some fairly durable and expensive kind of a social structure in place, be it a formal employment relationship, or a family or local community relationship, and that those things are expensive to create. They're durable structures. What we haven't had, ever before in history, is the possibility of a much more lightweight mode of affiliation.
Andy: Well, I'm definitely going to have to read that book, The Wealth of Networks, because I totally agree. The way we talk about that in the software business is in terms of fixed costs, how much does it cost to maintain your inventory talent, and scalability, how long does it take to get the new people that you need? And both of those, in the current ways that people build commercial software, are not very good. They can either hire people to work in their normal location, or they do outsourcing, which transfers the same model to some offshore location.
Jon: Right.
Andy: What we've seen in the open source world is a totally different model; it's not outsourcing, it's a single global team...
Jon: Yes.
Andy: And it's a single global team that's on demand. People work when they need to work, and we think that's going to be an important force in a lot of different areas. And that actually gets back to the way we designed Breakout. So The Wealth of Networks is a book about this. Breakout, the application that we're deploying at Assembla.com, is a piece of software about this. And we're proving it out in the software domain, but we've actually designed it as an extensible framework.
Jon: When you say that open source is about global teams, that's true, but those global teams are typically pretty durable constructs; people who are engaged, who are the core contributors to some open source project, aren't people who were recruited on the fly for some ad hoc purpose, right?
Andy: They aren't recruited on the fly, and that's an innovation that we're adding.
Jon: Maybe if you can rewind and talk through your early experiences doing this yourself, so that we have some context for what it is that you're now trying to automate and make scalable.
Andy: Well, let's talk about the objectives that I have when I put together a team. First of all, I want to work with the best people I can possibly get. That absolutely determines success in software, as much as in any other human endeavor. When we look at "inspired by open source" practices, the practice that we employ to get the very best people is competitive trial.
Jon: Okay.
Andy: On an open source project, people actually have to submit code that's good code before they get commit privileges. In the commercial world, we can translate that to competitive trials. People are interested in working on my project, they find out about my project because I advertise very widely, they submit their resumes, I give them paid trials. I offer them $500 or $1000 to do an actual task in the project.
Jon: Right.
Andy: And by working with them for a week or two, I find out a huge amount about how effective they are on that particular task. I didn't know why this was so effective until I read this book called Blink: The Power of First Impressions, which pointed out that when you're interviewing people there are many different prejudices and biases and things that you think about the people based on your first impression, and only a few of those things are relevant to the job. So in the open source process, and in my paid commercial competitive trial process, I am only paying attention to the things that are relevant to the job, and I'm never wasting any energy. There's no interview, there's no test, there's just work on the project. So it's extremely efficient.
Jon: So is it a challenge to find a task which is something that is able to be done...
Andy:...in a week...
Jon:...in a week, but is going to be illustrative of what you're trying to find out?
Andy: It's a challenge to set it up, so that new people can come into the project, download the development environment, and start work, and I spend a lot of time thinking about that. It's not a challenge to find tasks, because we just take tasks right off of the roadmap.
Jon: But there's a required context.
Andy: Exactly. So it's a challenge to set the thing up so that people can come in...
Jon: Okay.
Andy:...in a hurry, and that's the art of what I do. But that's also the art of how you set up a good open source project, so it's the same art and the same skill, and there are people who are good at it. It's actually what costs you, if I have to come in, if you're an existing software operation and I have to restructure you for this dynamic development.
Jon: You mentioned that you advertise very widely.
Andy: Well, I think of it more as traditional recruiting; we're going to advertise as widely as possible, starting with normal recruiting venues like craigslist, going out to the venues that freelancers use, like RentACoder, and we're building our own channel with Assembla.com. As we get Assembla.com ramped up, you'll be able to go to Assembla.com and post your profile in a much simpler way than the sort of blank wiki that you get now.
Jon: And that stuff will be syndicated out to those other channels, or it can be?
Andy: Well, it will be syndicated by RSS. RSS is built into Breakout, the application we use to Assembla.com, and basically, we use tags. I actually took your idea that if you give people tags, they'll self-organize, and they are doing it, so if you're interested in a Ruby on Rails job posting, you should be able to go to Assembla.com and click on the Ruby on Rails tab and find jobs postings, and you can also add that to your workspace. That's one of the key things that we're trying to build in.
Okay, so the first thing I want to do is find the best people, and we do that with competitive trials, open source shows us how to do that. The second thing I want to do is I want to get people quickly, so I don't think of these teams as being transient. The best team is durable and my goal is to get people who will work for me forever, if they're good, who are with me forever, because you never want to lose somebody who's good. But I want to get those people quickly, so I'm using the power of the Internet and massive global advertising, and hopefully this professional network, which is what I hope to think of Assembla.com becoming, to reach those people.
I need to have a community, essentially, a professional network, including a social network of people who work together so that I can reach these people. The Internet at some level is that, RentACoder, SourceForge.net, at some level are that -- we need to build a network of people who know how to work in this particular way, and a pretty big one. I think that there's probably a hundred thousand people that make their living doing this. We're going to find them, and we're going to work with them. So, getting people quickly, that's another aspect of what we're trying to do.
A third aspect is, we want to work together for a long time, so I try to put people on retainer, if I can. If I find good people. It's just too valuable, a good person is just too valuable to lose. But we want to make our costs variable, so we use week-to-week contracts and hopefully there's enough work floating around so that you can make a great living even if you're taking time off of one project. And that's a peculiarity of my customer base, which is start-ups -- their needs are very volatile.
That's about it! That's what we're trying to accomplish. And so it's a blend of what you can accomplish with open source globally distributed teams, and what you can accomplish with traditional, commercially driven recruiting and management methods.
Jon: The skills that you developed in yourself, in order to be able to pull these maneuvers off, included rapid configuration and deployment of software environments, right? So that these competitive trials could be farmed out quickly to other people. It also involved social networking: how do you find these people and bring them in? What are the other kinds of things from your own personal experience that you're now trying to incorporate into the platform?
Andy: Well, finding people, actually reaching, advertising, reaching out, communicating with people at high volume, is very important, and that's both a skill and a matter of equipment. So for instance, I built a customized version of SugarCRM to handle all the incoming resumes and profiles and responses. Well, that's not something that everyone's going to be able to do, so I'm trying to build that capability in to Assembla.com.
I have ten or twenty places that I advertise, including publications with no vowels in Eastern Europe, job sites in India, stuff like that. That's something that not everybody's going to be able to do. I need to integrate that, and put myself into the RSS stream, and so on.
As you mentioned, setting up the project so that it looks like an open source project. What we've done with Breakout, the application at Assembla.com, is we've made the permissions very flexible. So we put in Trac and Subversion, which are the standard tools for posting open source code, and managing the tickets around open source code, but we've wrapped around it this very flexible user management system, so that you can have open projects and you can have teams, very small, closed team projects so that you can easily bring people into those teams.
Jon: I made an account for myself earlier today and I was looking around some, and I noticed that you've combined some categories of messaging so issues and threaded commentary, for example, are showing up, possibly filtered or not, but in the same--what do you call it, a flow?
Andy: I call it Flow, yes. So for standard ticketing you have Trac. And so there's a couple of different layers here. Breakout itself is open source, and I've made it open in the sense that you can tack in applications like Trac and Subversion and get a single sign-on effect. That was key, because what I really wanted to do with Breakout was manage who's on what team, and who gets to see what. That's the core of this professional networking.
On top of that I've layered collaboration tools. A wiki -- all free, by the way -- I've layered a wiki and what I call Flow, which is a combination of all the different kinds of time series messaging that people do: discussion groups and forums, there's a feed reader in Flow, so you can pull stuff in from your tools, or from your blog and issue management.
The reason that I did this is because I was interested in getting some of the positive effects that I got with a similar design in my last collaboration application which was called Power Steering. What we found was that we experimented with merging issue management with discussion, so the idea is that as you're discussing something, either through email or on the threaded discussion page on your project site, the things you would be talking about would be issues: tickets, bugs, feature requests, tasks that needed to get done. And so on any one of these messages you can mark it with a priority that turns it into an issue, or a task, and shows up on someone's issue list. So once we had taken that step, we just decided to munge it all together. I don't know how it's going to go over, but I think it's great. We built a pretty complicated feature called Flow in which there's a filter bar at the top, and depending on which filter...
Jon: Yeah, I was just playing with that.
Andy: If you want to see just the headlines, you get a headline view of a forum board. If you want to see the most recent, you get the most recent view of a forum board. Priority, you get the task view, it's just the issues. And finally threaded, which is more the mailing list kind of discussion view.
Jon: So, in terms of discovery, there's full-text search and tagging, basically?
Andy: Yes. The basic object in Assembla.com is the space, which is like MySpace's, but with add-on tabs, for things like Trac and Subversion, professional tools and with permissioning, so you can add a team to a space and do work that's private. We have tagging for spaces, and we also have full-text search for spaces, and we'll be expanding the search as time goes on.
Jon: So right now I'm searching within rather that across a set of spaces?
Andy: Well, the idea is that you're searching across a set of spaces, but it's permissioned. So, you should be able to... when you go and search, you're searching all the public spaces plus all the private spaces that you have access to. That's actually technologically not an easy thing to do. But we thought it was very important in this situation where we have a general platform for professional networking. Professionals are people who work in a lot of different permission groups.
And if you do search you'll see that there are some options there. One of the options is to just search the latest space, all spaces - "my spaces", which is your private spaces and then the latest space. So if you want to just search in your flow in your discussions for the latest space, you click that and you'll get a private search.
Jon: So if somebody wanted to just get their feet wet with this thing, it is free for small projects or for individual use...
Andy: It's totally free. Our goal as a business is to get the most projects on here and the most users, because we actually make a really good margin when we sell you all the other services that make it possible to run one of these commercial distributed teams.
Jon: So let's talk about what those are.
Andy: Well, recruiting. Payment services, so payment and escrow, the kind of thing you get from RentACoder or oDesk. Indemnification, if you're an investor-funded company you need to know that somebody is looking at all the code and making sure that the license is clean. For $100 a developer a week, we can do that. And then there are additional application services. So, think of Assembla.com as the next level up from something like oDesk where they do time and billing. And portfolio reporting, so if you have a lot of these projects running. So it's also a competitor to CollabNet.
We haven't added those features yet, or we haven't released them, but if you're a big company and you have a lot of these projects running you need to see portfolio views. And we'll sell you that. If you can imagine people figuring out how easy this is, and how great it is to work with these on-demand teams, if we can get up to a certain scale - and certainly the scale is available - then we'll be able to make a fair amount of money. And we'll still be able to provide free support at a much more sophisticated level than this for the full life cycle of a software project.
Jon: So what do you think about the "walled garden" effect? It's always an issue when you approach anything that aims to be a professional network or to be a repository of a certain set of things. The questions are always, "Can I get everything out that I put in? To what extent -- if I have pre-existing relationships, pre-existing data -- can I move things in and out, federate with other networks and other repositories?" What are you thoughts along those lines?
Andy: I thought about part of it, but I didn't think enough about another part. The part that I thought about was: if you're a project or you're a developer, how do you make sure that we can link to all of the other things that you do? So if you go to sites like RentACoder and oDesk -- which are low-end versions of this -- there are a lot of restrictions on what you can post as part of your profile, and there's no restriction on what you can do with Assembla Breakout. And in fact, if you don't like the application, it's open source, you can fix it, you can become part of our development team. That's the part that I did think about, was freedom.
Jon: Has that happened yet? Have any of the users joined the project?
Andy: No, I'm still running my regular recruiting to bring people into the project. But if people want to join, I'm out there and I'm doing paid trials and all that stuff.
What they have done, is they have reminded me about the stuff that I didn't think about. Which is "How do they get their data out?" Anybody who uses this thing seriously writes me an email or posts something on the suggestion board that says "Andy, I need to be able to download my Trac workspace and back it up myself." Those are things that we've got in the queue and we're going to do. I did make sure that I put RSS in and out. You can read RSS into Flow, which is the simplest possible way to get data from one app to another. So, for instance, Trac spits out RSS, and you can also get the RSS out of Flow.
We're trying to break that down bit by bit, but it wasn't the first thing that I addressed. Let me tell you what I did do with this app that's really interesting. We self-consciously designed it so that if it works for software we could take it to other applications, like public health and managing the response to avian flu. Or putting together legal teams.
Jon: Sure, because a chunk of it is just issue tracking and communication, Wiki, and things like that.
Andy: Right, the key part of it is the user management. Getting user profiles and figuring out what teams they belong to. And under that, once they belong to teams or spaces we give them collaboration tools. Those are all generic. So what we're really trying to do is combine social software and enterprise software. Social software is software that's very easy to adopt. You come to my site, you bang on the button, you fill in a form, you have a profile. And profiling is what drives social software. And underneath that are applications that we know are very easy to adopt, like wikis. We've put all that in, in a generic way. Once you've created a wiki, and created a space around that, and a team, we've added on professional tools like Trac and Subversion. And if you look at the site, it's actually a little bit jarring. You say, "Hey I want Trac," and you push the button to create the Trac tool. Two seconds later you have Trac for your team. Its software that's really on demand, is what I call it, if you think about Breakout as a platform.
And, you go to your Trac workspace, and what's jarring about it is that you're not in Breakout anymore, you're in trac. What we've done is we've taken best practices, a very specialized application for making code -- which is what Trac and Subversion is -- and we've tacked it into this generic collaboration application. Really just layering our team permissions on top of it.
But that technique that we use - we've created a very simple set of web services for doing that - can be applied to lots of other applications. So if you wanted SugarCRM for your team, or Alfresco for your team, we can tack those things in as well.
Jon: I saw on your architecture chart a reference to a layer of web services in between the open source stack and the applications. But, in principle, this could be integration by URL, right? You could just link into the thing. So what is that web services layer doing?
Andy: It's a very simple web services layer that's designed to accomplish two things. First of all, let me back up and say why I created this architecture. Because if you're building a professional network - let's compare lawyers to software developers - a lot of what you want to do is exactly the same.
You want people to be able to sign up, post their profiles, manage who gets to see their permissions, look at job listings and project listings, create collaboration spaces, have access to these generic collaboration tools - like wikis and Flow. A lot of what you want to do is the same, and at the other end, the enterprise software end you want to be able to do management reporting. So those are all generic capabilities.
But, when you get right down to it, programmers make code. And they need tools like Trac and Subversion. If you're not a programmer, that's useless to you. These are specialized, high-value applications that you need to be able to tack into the team workspace to make this actually useful. And that's what you focus on. You're a software guy, and you're focused on the tools that actually have value for you. But if I was dealing with lawyers, I'd be tacking in a whole different set of applications around client management...
Jon:...document management...
Andy:...corporate book, and document management. Exactly, and that's one of the partnerships that we have, is to do that. We needed to make it easy to tack those specialized apps into the workspace. So we created the simplest possible web services layer. It basically has two functions. One is: create an instance. So, whatever app you have, create an instance of that app. That is integration by URL, essentially we'd put in our database the tools server - the server where that app will be running.
The other service that we provide is login, and authentication, and permissioning. For a given user, do they have access to this instance, and at what level. We've dramatically simplified how permissioning works. So, most sophisticated enterprise systems have a couple different levels of permissioning. In Breakout, you're either an owner and you have all permissions, or you're an editor, you can change things, or you're a viewer, you can see stuff but you can't change it, or you don't have any permission. You have to figure out how that maps onto the system of choice, but it does map.
So, we've covered a lot of ground here, but you can sort of see how the thinking evolves. You start with open source teams, how do they work, what makes them work. How can we make it easy to use that technique, which is very, very powerful if you apply it globally in commercial software, and then how can we take those same techniques and apply them to other areas of endeavors so we can get this effective on-demand teams...
<>Jon: You're just ramping this up, so it's probably a bit soon to be talking about case studies and experiences that...
Andy: What I can talk about is the experience that I've had running these teams. Putting them together and running them. So I have a lot of experience in that area. What's new is my attempt to package that in Assembla.com. And I can tell you that we have a major transition that we need to go to with Assembla.com that we haven't gone through, that we'll go through in about a month. Which is, we need to make it very easy for people to come to the site and profile themselves, since that's what drives membership in social software situations. What we're doing is we're creating form-based registration -- instead of just getting a wiki where you can profile yourself if you know how to use a wiki -- you'll be able to fill out a form and it'll spit out your home page.
Jon: I guess we're just not there yet, but it sure seems to me like the way this ought to be working is that I should just be able to point your site at my canonical file of XML in some format that is, in fact, maintained by me on my site, and syndicated out to you and to whoever else needs it, right?
Andy: That's a great idea, and I know there are some people that are working on that.
Jon: Well, there's a lot of people working on it, it just hasn't come together yet.
Andy: That would make my life a lot easier.
Jon: The gating factor in a lot of situations is exactly that process that you just described. "Can I actually stand to fill out another set of forms about myself?" I had an experience with LinkedIn at one point -- and I don't actually use LinkedIn, it doesn't do much for me, because I lead such an atypically public and transparent professional life. But at one point somebody asked me for a recommendation, and the form said: "Identify your relationship to this person," where the choices were "they worked for you," or, "you worked for them." None of that applied. The only contact that I had ever had with this person was that once I had mentioned software that he had written in an article. And the other contact was that we had interacted briefly on a message board someplace. When I queried google for his name and my name, those exact two things came out. The answer to the question, "What is your relationship to this person?" was the google query.
Andy: Well, you could look at my responsibilities being maybe to go out and figure out some way to integrate with places where people already have profiles. Or I could try to figure out where the standardization is going. Who's likely to do the best job in this? I think it's a great idea, and that's actually one of the reasons I got in touch with you.
Jon:I suppose that FOAF is the closest that we have, and it doesn't really come very close to this domain. I know that there are some HR XML standards out there, but I don't get the impression that there's any traction around people using that stuff on a personal, freelance, professional basis to characterize themselves in a way that's intended to be syndicated. That just doesn't seem to be happening.
Andy: It doesn't seem to be happening, no. The stuff that I've seen is all around identity management for authentication. "Can I log in here? Can I log in there?"
Jon: Well, I suppose one way to do this -- although it might not be obviously something you would want to do -- would be that once I've got a rich profile at Breakout, that that at least is syndicatable outward in some format that you would choose to evangelize.
Andy: That would be great. I'd love to get to that. I don't know exactly where this is all going to go, but I've tried to make the system as open as I can so that we can do things like that as people suggest them.
Jon: I saw on your site some questions about how does all this compare with SourceForge. I suppose another question that somebody might ask is, "How does this compare with BaseCamp?"
Andy: BaseCamp is, right now, a more sophisticated way to keep track of tasks. Over time, over the next few months, I hope to reach the same level of ease-of-use for task tracking. Within a few months I don't think there's going to be any reason to use something like BaseCamp if you can use Assembla.com and you're working on a software project, since it's really a very specialized tool just for working on software, whereas BaseCamp is generic.
BaseCamp is a very self-conciously horizontal tool, and I think that the guys that made it have done an amazing job at building a business around something difficult like generic collaboration. Assembla.com is for software projects. It's not as mature as BaseCamp in terms of the usability, hopefully we can take care of that. The other interesting thing about BaseCamp -- and pretty much all of the other collaboration tools out there -- is that they assume your project is the only project out there.
They don't have the public face, the way Assembla.com does. What we've tried to do with Breakout and Assembla.com is imagine that every project is embedded in this global, professional network. And that some aspect of it is going to be publicly visible, or might be publicly visible. So, rather than thinking of it as one project at a time, we're really starting with the idea that it's one pool, and then allowing you to restrict permissions on particular spaces.
Jon: What will be interesting over time is, of course, there are multiple global pools. And people are likely to be involved in several of them. So the way in which those things can federate is going to be an interesting question.
Andy: Yeah, and you're right. You, consistently in our conversations, you've brought up things I didn't think about. I've sort of thought about, "What's my responsibility for a user who's working in many projects on Assembla.com?" Some of which are very personal and private, some of which are enterprise, and some of which are open source and public. And we've created a permissioning system and a way of thinking about spaces that allows a person to do that on the site.
The next challenge is, well, there's lots of different people, lots of different sites and databases that these people participate in. How do we integrate that? That's a bigger challenge. I'd like to go after it. I can't do that until I've hit the first target. But, in answering the question, "How is this different conceptually from BaseCamp?" you can see that thinking about every space -- starting from the point of view of "my spaces" -- every space is an opportunity to be part of the global network. It's a little different philosophy.