DDJ: What is on-demand collaborative software development?
JR: We can begin by picking it apart: "on-demand" means we've got the site already up and running for you, you just log in and start your work. "Collaborative software development" is maybe a bit trickier: it's not just that the software developers work together. Rather, it's a particular style of cooperation, a style that emphasizes community responsibility for training, recognition, and decision-making. As well as, of course, the basic thinking and typing that create the software. The complete phrase is even more interesting than the sum of its parts, though. Collaborative software development can be done with very basic tools—probably the minimum set would be e-mail and version control. But the collaboration part suffers: There's no consistency in the distribution lists, there's no history to research past decisions, there's no public face to draw in new contributors, there's no combination of tools to produce emergent value. All these things are possible, by adding to the tool suite and by extending and connecting the tools, but this begins to be significant work in its own right: At some point, you wake up and realize you're hacking on your environment, instead of your product. So the "on-demand" part of "collaboration" turns out to be crucial: We create and maintain the environment, so you can do your own work.
DDJ: Can you give us some examples of collaboration tools and describe what is unique about them, as compared to other software development tools?
JR: In this combinatoric sense of collaboration I'm using here, it's not really about the individual tools, but about their synergies. Everyone has e-mail; if I claim e-mail is key to collaboration, you yawn. Well, I do claim that, but I claim a lot more: The collaboration e-mail needs to be captured and archived and searchable, so people who come to the party late can catch up; [it] needs to be seen by the wide community, even when only a few are actually contributing to any one discussion, so that everyone absorbs the general direction and culture; [it] needs to be available for people outside the community to peruse in order to judge the health of the community—because you can't afford to reuse components without basis for trust in the community...that they've done the job well [and] they'll be there when you need them. So, it's e-mail plus search plus centrally managed e-mail distribution lists, plus cultural factors like broad participation and openness to the outside.
DDJ: How closely intertwined are collaboration and open source?
JR: The open-source community kind of stumbled upon this model of collaboration. They had some challenges in common with all software development (like rapid production of quality code), some challenges that were new to us all a decade ago (like the ubiquitous Internet), and some challenges that remain unique to the open-source situation (like the casual join-and-disappear contributor). They worked out, sometimes consciously and sometimes by accident, a collection of solutions to these problems. Some are contained in the tools, some in the process, and some in the culture. In the end, the open-source community has managed to accomplish some truly amazing things, occasionally even things that the enterprise community has tried and failed. But these tricks aren't intertwined with "open source" per se. Each is an effective response to a particular problem. Open-source development projects consistently face many of the same problems, and apply many of the same solutions, but the same problems appear in enterprise work, and the same solutions can apply as well. The only really tricky bit is that there do in fact remain some actual differences between open source and enterprise; the enterprise user must not only pick out successful open-source solutions, but avoid those that solve problems that the enterprise user doesn't in fact have.
DDJ: How important is the SaaS delivery model to distributed development?
JR: Central storage is really key, both to distributed development and to the governance that's ever-more important to enterprise shops. It gives equal access to all, it allows "one-man offices," and it provides the maximum possible economy of scale for the administration teams. You can work around some of these, in a more complicated system, by adding even more complexity, but you may not actually gain anything by such a trade-off. Now SaaS—that is, a commercial relationship where one company provides that central service for another—isn't in itself crucial. Particularly in software development, it's typical that the customer is competent to provide the service themselves. The question here is: How do you want to spend your development dollars? On developing your environment? Or on developing something your customers will actually pay you for? So SaaS...reduces the opportunity cost of having your prime developers fiddling with their environment instead of their work.
DDJ: How does an organization protect its intellectual property in a world that is defined by open source and distributed teams?
JR: Well, of course, you have to work with your lawyers. I'm not even my own lawyer, let alone anyone else's! But the key point is to separate out the places where you have value to add, from the places where you can let someone else do that. Secondly, some of the existing open-source licenses are concerned about how you "combine" or "derive" your work with or from the licensed stuff. There's a lot of variation in the licenses; you have to read them closely...But they all have some sense of how you can draw the line between their stuff and yours, and you need to respect that. Sometimes this will reach clear into your architecture, but more often, it can be handled simply with careful packaging. On the flip side, there's the stuff you give back to the community. And you should—that's why it's called "a community"! You should assume that a part of the "cost" of using open-source components is returning something to the community.
