Interview: How Software is Built

I very much enjoyed doing this interview for the Microsoft-created How Software is Built series. In terms of length, it may go against the less is more mantra, but for that I blame the skills of Scott Swigart and Sean Campbell, who raised some very interesting questions and insights. The interview covers building communities, bridging academic, open source and commercial models, the history of Mylyn and Tasktop, and innovation ranging from IDEs to the iPhone.

Sean Campbell: To start, can you give us a little bit of your background and then blend that into Tasktop and the Mylyn effort?

Mik Kersten: Sure. I’m the president and CTO of Tasktop Technologies and the lead of the Eclipse Mylyn open source project. What I really enjoy doing and getting lost in is building tools. I’ve been doing that ever since I got involved with the AspectJ project as a student back in 1998. This cool new aspect-oriented modularity technology was emerging up from Xerox PARC, and I started implementing a web-based desktop UI with it. I’d just made the switch from Emacs to Visual J++ 6.0, which wasn’t the easiest transition. But Visual J++ had code completion and integrated compilation, which I quickly became addicted to since they accelerated my ability to code. That was the first time that I realized the amazing potential of tools to make us more productive.

A few years later, I had dinner with Anders Hejlsberg and the product manager from the VJ++ 6.0 team and had the opportunity to thank them personally for that amazing product. I also had to take that opportunity to gripe about its very restrictive extensibility API. While finishing my bachelor’s degree I had extended Visual J++ with some rudimentary support for aspects, which got the attention of Gregor Kiczales, who was leading the AspectJ team at Xerox PARC. So I joined the AspectJ team and created the first AOP tool support, in the form of a common tool framework and extensions for JBuilder, NetBeans, VisualStudio, and even Emacs. But with each of those integrated development environments (IDEs) I kept hitting major barriers, because none of their APIs were open or extensible enough to support a new programming language.

Then came along Eclipse, which finally gave our tool support efforts a feasible path. As the AspectJ project transitioned from research to an established technology, I moved with Gregor Kiczales to join Charles Simonyi at Intentional Software. We were trying to build on the practical ideas that had made AspectJ work and incorporate them into Charles’ new domain-specific language workbench. But thanks to some great exposure to user interface innovators at PARC, I kept having these ideas that statically typed OO languages were good enough, and that the real problem facing software development was a mismatch between the tool paradigm and the way programmers work. The bug that all the IDE tools seemed to have is that of taking the compiler’s point of view and overloading the programmer with structural slices of the entire modularity of the system. That works fine for toy examples and demos, but not when you’re debugging a multi-million line web application. I wanted to better understand what it would mean for tools to take a more user-centric point of view.

So I left industry, went to the University of British Columbia to do my PhD with the amazing Gail Murphy, and made this thing that’s now called the task-focused interface. It shifts the tool paradigm from being structure-centric, where you get to see the same structure as the compiler and the execution environment sees, and making it task centric instead. What you see is what’s relevant to the work that you’re doing as your building the system. Gail and I validated the implementation of that with the Mylyn open source project, by monitoring how the day-to-day productivity of 100 programmers in industry was affected by the task-focused interface. I saw that there was a statistically significant increase in productivity. After that, the magic of open source communities kicked in, Mylyn became a part of the default Eclipse distribution, and it now has hundreds of thousands of users. I got very excited about the potential of this new task-focused approach to user interfaces and wrapped up my PhD by showing that this technology also works for non-programmers. Just over a year after defending my thesis we released Tasktop 1.0, which is starting to bring the same productivity benefits to a growing number of non-programmers.

Sean: Is Tasktop a commercial enterprise on top of Mylyn?

Mik: Yup. Eclipse Mylyn is an open source project that provides the framework and APIs for the task-focused interface, as well as reference implementations that can be used by programmers. There’s integration with Java programming and with plug-in development, as well as with Bugzilla issue tracker. Tasktop and other extensions to Mylyn integrate that framework and that way of working with other commercial products and services. For example, Tasktop has commercial and for-pay extensions of Mylyn to make it work with Outlook email and tasks, Gmail, and Google Calendar, as well as its new take on the web browsing experience. Similarly, the SpringSource Tool Suite, which uses the task-focused interface for enterprise Java development, is built on Mylyn and Eclipse, and is another closed source offering that offers these productivity benefits. There are quite a few of examples of this sort of split between open source framework and closed source product within the Eclipse ecosystem. An interesting dynamic of the Eclipse ecosystem is that the frameworks are vendor neutral. Anyone can contribute to them, including competitors, and then individual companies provide closed source offerings on top of the open source.

Scott Swigart: You mentioned that you’re targeting not just developers now, but information workers. Talk a little bit about that.

Mik: Sure, but let’s start with a quick overview of the developer side of the tool space, since that’s how the Tasktop technology evolved. The trend of IDEs and other development tools over the last few decades has made files the central unit of what you work on. Files are where you browser your classes, whether it’s C# or a Java. They’re where you put your XML descriptors, and your interaction is around files. That worked great when our systems were composed of dozens or maybe hundreds of files, but if you look at an enterprise application, you’ve got hundreds of thousands to millions of lines of source code broken up across countless files and libraries. While machines have no problem dealing with buiding systems that large, thanks to incremental compilation, fast processors, and lots of memory, our monitors just can’t fit all that information. And even if they could, we couldn’t process it.

The idea of the task-focused interface is to make tasks the core unit behind everything we work on. Consider that for any bug that programmers fix or any feature that we add, we only care about the subset of the system that’s relevant to the task. Mylyn has made tasks just as primary a part of the IDE as files are. Since that time, we’ve seen some task integration in other IDEs, although Mylyn’s taken the concept to another level and re-aligned the entire user experience around it. When working with Mylyn, you activate a task, and as you write and navigate your code, everything that you touch becomes a part of the context for that task. You can multitask with a single click by activating a different task, and now you see all of the Java files and methods and XML you were working on last week. Instead of manually managing the set of open files and classes, the task context is actively managed for you to highlight the most relevant parts of the system and hide everything else.

Task switching is almost instant, which is important for those of us who are constantly multitasking. On the Mylyn open source project, every single bug that we have has a task context attached to it, so that if someone wants to start working on it to help us resolve that bug, they can pick up exactly where we left off. This capability lets us apply dozens of patches a month from numerous contributors. We realized early on that the problems of information overload and multi-tasking overhead were not just something that affected programmers. It’s a very obvious problem for programmers who worked on very large sets of structured data. But the problem is similar for anyone who needs to access dozens of files and web pages as part of their workday. We end up making shortcuts, losing things, having multiple copies of documents and manually managing email attachments. Early on I started using Mylyn’s task-focused interface for managing my open source, consulting, and PhD work. We then ripped out all the programming specific extensions, made the framework more generic, and started to prototype integration for non-programmers. For people using Microsoft Outlook, we brought their email and tasks into the task-focused interface. For those using web applications, we also integrated Gmail, Google Calendar and other key task and time management apps. We embedded a web browser so that all the most frequently and recently accessed web documents would be instantly restored when you returned to a task. In my PhD thesis, I kept referring to the result as the task-focused desktop. A few days after wrapping up that thesis, we founded Tasktop Technologies. We are still sticking with our programming roots and have a programmer version of Tasktop for Eclipse users as well as a standalone Windows application for everyone else. Since we build on a large body of open source frameworks and tools, we made a very clear split between Mylyn, which is a framework and a free reference implementation for programmers, and Tasktop, which provides a fully supported product and integration with proprietary applications and web services.

Scott: So if it’s SharePoint integration or Outlook integration, then that’s fairly obviously going to be a Tasktop implementation. On the other hand, if it’s the generic framework and that kind of stuff, then that goes into Mylyn.

Mik: Exactly. We want the framework to be vendor neutral, because it is the first implementation of this new technology, and by keeping it open we have been encouraging the integration that has made it a de facto standard for tasks in Eclipse. We continue to put considerable effort into making it easier to build on the Mylyn APIs. I think we’re getting close to two dozen different integrations form various companies that range from Atlassian’s JIRA issue tracker to CodeGear’s JBuilder. There are also various open source projects building on the same APIs to integrate them with their own task, bug, and project management tools. And the neat thing about these integrations is that once the task repository has been integrated, all of the benefits of the task-focused interface just work. This includes additional features of Tasktop, such as to-the-minute time tracking and reporting. One of our top priorities is supporting this rich ecosystem integration, because we know that Tasktop cannot provide integration to the countless task management systems out there. We’ve also helped bootstrap some of the companies on the integration, with consulting services to companies including Spring Source, CollabNet, Rally, and Atlassian. One of the neat things about our ecosystem is that even though there are competitors within it, everyone benefits from the common goal of improving and refining the open source framework. This helps provide incentive for patches and other contributions.

Scott: What led you down the path of thinking that maybe tasks were the right way to handle this problem of information overload? Mik: Actually, a few things happened at once. I was getting RSI from spending too much time coding AspectJ releases during crunch times. I was trying everything short of cutting my workweek in half, but nothing worked long term. As I analyzed what was going on, I realized that mouse clicks were the biggest part of the problem, and that I was repeatedly clicking to find and re-find the same information.

Most IDEs and productivity tools are typically optimized for showing you one place in document. We often try to structure our work around one folder, package, or directory in order to make relevant information easy to access. But what we learned from aspect-oriented programming is that no matter how we set up a hierarchy, for some tasks we will need to access information that crosscuts the hierarchy. When programming, we often need to refer to methods that span a call stack. When writing a proposal, we often need to access historical versions as well as related spreadsheets and online documentation. The end result is that with a conventional user interface, we spend an inordinate amount of time searching and clicking around to get at the information we need. To reduce this clicking, we need a user interface that puts everything you need on the screen so that it is only a click away.
To test this approach to reducing clicks, in 2004 I made a visualization toy that showed you only the editors that you were touching, and the relationship between them. I integrated the core ideas with Eclipse, started using it myself and did a small user study on some professional developers at IBM. What most of the study subjects indicated was that the work they doing was chunked. As your work populated the visualization, you wanted built up a valuable set of documents that you may want to recall later or share with a co-worker. The remaining question is what defined the boundaries chunks? With programmers, it was pretty clear that people were using issue trackers, bug trackers, and other project management tools to define their chunks of work and the related document context. Since the user knows best when they’re about to start working on a particular task, I implemented a facility for indicating which task context should be active, and a task list for switching between tasks. There was a fair amount of backlash in terms of my thesis committee and others saying, “No, no. People will never proactively indicate what they’re working on, it’s too much effort.” In response, we focused on making the user interface simple and streamlined, to the point where it only took a single click to indicate what you were working on and return to it later. You end up seeing an immediate benefit and the gratification of a focused workspace. In the end, after working on only a few tasks in this way, people get hooked.

Scott: How does that integrate with different methodologies, such as agile or a test-driven development methodology?

Mik: As information workers, whether you’re a programmer or a project manager, you work on tasks. How you define a task depends on our development process and company structure. “Task” is just a short and nice word that we chose to describe all these things ranging from bug reports to marketing events. For example, when using Tasktop with Rally, a web service for agile project management, your tasks are user stories, and the subtasks under those stories are defects and actually things called tasks. This is the agile scheme for tasks, which fits very nicely into the tool. Once you return to a use case, you see all the relevant requirements and documentation opened instantly. As another example, with a click in Mylyn, you can make a task from a JUnit failure. So if you’re trying to make some component work, you’ve get pen test failures and you can easily make tasks or subtasks out of those and start fixing them. In a bug tracker like Bugzilla, your tasks are bugs. In Tasktop’s Gmail integration, your tasks are email threads. The rich client provides you a single UI for managing all this information, and caches it all on your desktop machine in order to speed up task opening and to support offline work.

Sean: Let me ask you a question in a different area. You went from a project that had its genesis in some academic work toward a commercial model. What did you look to for inspiration there?

Mik: What became evident from my research is that the way we’ve been working now is way slower than it should be. That it’s way too cumbersome to collaborate, and that there’s a way to fix that. That was really the seed of the whole thing, and then the user studies gave me and Gail enough confidence that this method had merit. Seeing a statistically significant result in improving study subjects’ productivity also helped. So we knew that that there was value. But we also understood that this new approach was trying to change the way people work. No one asked to work on tasks instead of documents, and no one asked to have to activate tasks. In order to deliver this value to developers and others, we had to make the technology incrementally adoptable. At the same time, we needed test it further in as realistic a manner as possible. We didn’t have the resources to reinvent a widget set and application framework, so the extensibility of Eclipse was very appealing. We just wanted to get the technology into the hands of users, and the best way of doing a broader validation in the field was to put it out there as open source.

That did leave us with a business question. If we released the core technology as an open source, would we be giving away too much? I always wanted to commercialize this technology, because I believe that a company is the best vehicle for delivering the whole vision that we have for transforming the way that people work. We need a lot of programmers working on it, we need a rich ecosystem, and we need partners to get it broadly adopted. On the flipside, I learned from my own experiences extending tools that frameworks should be open source. So we put all of these lessons together and came up with the current split between Mylyn, the Eclipse ecosystem, and the Tasktop products. The split has allowed us to innovate very quickly and to have the benefit of a constant stream of user feedback for improving the fidelity and integration of the task-focused interface.

Sean: You mentioned that you felt that a company was the best way to do this. It’s interesting to consider where technologies get born and what is the right pairing for them, to accelerate them at different points in time. What were the key reasons for thinking that taking it commercial would be the best thing for it?

Mik: If you want to deliver tools that provide a transformation productivity increase, you need significant resources to create that technology and deliver its value. You can put in countless volunteer hours and try to pool a community of like-minded volunteers to help out. We’ve seen that work over and over, in Apache for example, for creating implementations that are fairly well specified, because you can have all kinds of people hacking in their spare time to make a web server or a kernel extension work-a different implementation of something that’s already appeared. But for a genuinely new idea, my experience is that reducing the time to impact means having people working closely together, whether they’re remote or in the same room with a whiteboard. It is rare for volunteer-only efforts to create and support a genuinely new technology. What the typical user wants is a polished and supported product, and I believe that a company is the best vehicle for delivering that. I felt like I had two choices. One was to try to take the task-focused interface into an existing company and make it work there, and the other choice was the startup route. I had two key concerns with the startup route. One is whether we would be able to dedicate enough funding to the open source portion of the effort, especially given that we are bootstrapping the startup.

The other concern was the fact the task-focused interface is something of a disruptive technology, which means that we needed to invest a tremendous amount of effort in the user interface and integration in order to make it easy to adopt without forcing people to give up their existing tools. But Christensen’s “innovator’s dilemma” dictates that big company customers do not ask for tool vendors to deliver them genuinely new technologies. Disruptive technologies end up growing organically around some community of users that adopt it, and can grow quickly if a tight feedback loop is established with those early adopters. I don’t think there’s any better mechanism to bootstrap a community than open source. With Tasktop, we have been able to deliver a cool new tool, support an open source community, and bootstrap a startup. I believe that a mixed closed and open source approach is a much cheaper way of bring new technologies of this sort to market, since it both leverages the community efforts and gives back to it. In the end, it means that we are able to deliver a solution that’s both better and less expensive. It also means that we get to have fun being closely engaged in constant design discussion with some of the great minds in the Eclipse community.

Sean: What do you think about the role of innovation when it comes to open versus closed source projects? It’s one of those sticks that both sides like to use to beat the other up with, I think. One side says, “We’re more innovative, because we have a community.” The other side says, “Because we can pay people and do things that somebody normally wouldn’t spend time on, we can create new things out of the ether that would never have been born otherwise.” What aspects of each community do you think lend themselves to more or less innovation?

Mik: My sense is that the open and closed approaches are akin to two different tools at our disposal, and each has its own merits for delivering innovation. If you’re Apple, you’ve got a ton of value in the secrecy and the marketing buzz behind big product launches, of products that are incrementally innovative. Jobs might call the iPhone revolutionary, but it’s just an awesome packaging of a bunch of things that already existed. In 2000, while at Xerox PARC I was playing with a smaller mobile device that had an accelerometer-based UI. It’s not revolutionary-it’s an incremental innovation that takes good advantage of Apple’s knowledge about exactly how to deliver that type of innovation, and I think it can make sense to do that in a closed way, without open channels for input of an early adopter community. There’s another kind of innovation, where you know the idea and the vision, but you don’t know what form it should take. And that’s been exactly the case with Mylyn and with the task-focused interface. It hasn’t been around for that long, but it’s taken major turns in how the user interface works, and how it integrates with the tools we use, and what tools it integrates with. Without a very active and engaged early adopter community, we could not have both created and refined the task-focused interface to the point where it could go from whiteboard to hundreds of thousands of users within a few years.

Scott: What Apple did with the iPhone was really interesting, but it wasn’t innovation in the sense of invention. It’s innovation in the sense that they packaged up a lot of things that already existed in a really great way. They built a really great experience out of a lot of bits and pieces. But if you don’t necessarily know exactly how you’re going to get there, if what you’re doing requires a lot of invention, and if you’re looking at shifting people to a whole new paradigm, then having people go off and work for 18 months in a dark room isn’t necessarily the best way to go. It sounds like what you’re saying is that open source allows you to be iterative in a way that you just can’t be if you’re trying to do a closed source non-transparent release every nine months.

Mik: That’s exactly where I’ve come to with this thinking about using open source as a tool for invention. Actually, I don’t think it has to be open source-it can be openness in general. For example, the way the GUI evolved at PARC is that there was a rich community with a lot of open interaction of engineers in Palo Alto, who were talking to academics, and they built up all this amazing expertise. Maybe if you assume you can get exactly the right mix of people into an ivory tower and motivate them to come up with something that’s a really transformative technology, you can succeed. But it seems a lot harder, because either the world will have changed while they were hidden away, or you they will have missed some unforeseen conversations that open the project to new lines of thinking. Open conversations have really helped the trajectory of Tasktop, ranging from the academic dialog to threads on bug reports. They help us understand what’s feasible with the technology and what future directions are most relevant. For example, we’re now building more on the web experience, so we’re monitoring more of the way web applications work in order to extend the reach of task context, and we’re having more conversations with people doing web apps in Ajax and RIAs.

And those are just invaluable for understanding where we can go next. Another type of conversation that I think is incredibly important is with the people actually using the technology, particularly since Mylyn is a technology that’s designed for collaborating and managing discussion and feedback. User feedback for us takes the form of tasks, and on the open source project in the past year, we’ve processed 1,500 of these feedback tasks. Some have had discussion threads hundreds of comments long. That collective knowledge tells us where the tool and technology should be heading over the coming years. With a short release cycle, we’ve given people enough incentive to continue giving us their feedback, since they are rewarded with an impact of the tool. We can’t incorporate all the feedback, and a bit part of my job is keeping the UI consistent, but we always encourage interested users to contribute an implementation when a particular feature does not fit within the committers’ priorities. And often enough they do. The fact that a community can shape an idea and integrate it with the way they work, instead of just our own preconceptions of how it should work, means that in the end, you can reduce the time to impact of the technology from a decade to the three year time frame we’ve been seeing with Mylyn.

Scott: It sounds like Mylyn is continuing to do that innovative, “we don’t know exactly where it’s going to go” kind of work. At the same time, a lot of the commercial stuff that you’re building on top it, like the Gmail integration or the SharePoint integration, are maybe a little more like logical extensions. Would you say that those things don’t necessarily require that same level of collaboration and brainstorming that the core Mylyn framework needs?

Mik: You’ve hit that nail on the head. We don’t need that integration between the framework and SharePoint or Google Calendar to be open source, because it’s just integration. It’s got really neat things in the way it works, it’s got some neat UIs, but it’s more about creating a smooth user experience than invention. At the same time though, we see an interesting effect because of the fact that we use same feedback process for bug reports and enhancement requests within the Mylyn user interface that we use with Tasktop. An interesting thing that we didn’t predict is that that same openness and open dialogue with users has been working on the closed source tool. We did not expect to get the rate of bug reports and enhancement requests that we are getting on Tasktop. It’s on the same trajectory as the Mylyn rate, even though Tasktop has only been out since March. It’s in part because we have put a lot of effort into feedback facilities in Tasktop. In other words, we’re bringing the same open dialog that we’ve been spoiled by in open source into the closed source tool. It is interesting that you can get some of the openness and dialogue with users, as long as you provide them enough incentive. I think the key is that they have to know that they can affect change, that their input means that down the road they’ll get a version of the tool that’s more tailored to the way that they work. So that begs the question, what needs to be open source?

Scott: Maybe what open source gives you essentially is a way to augment your development team, because you’ve got people who can actually code on the product and submit patches and things like that. But that same level of collaboration and transparency and input isn’t necessarily a function of open source. Open source requires it, but maybe you can get that same level of collaboration without open source. What you can’t get is that kind of volunteer developer pool.

Mik: Right, and we can consider this decision from the point of view of economics-do you think you’re going to get more out of casual contributors working in their spare time than you will from proprietary ownership of your source code? If you’re building a framework, you may want to use open source in order to establish it as the de facto standard. If you’re in a space where a standard requires agreement from multiple vendors, the right vehicle for this could be a vendor-neutral ecosystem like Eclipse. Consider Tasktop Technologies. We are a startup, so it is a big advantage for us to be delivering a solution on top of a de facto standard that we created, and the volunteer effort helped make that implementation viable. So open source has been a very clear win for us.

Scott: There are obviously a lot of philosophies out there in open source and free software, but one voice is the free software philosophy that there should basically be no closed source. I could see some people objecting to the approach of using free development tools and the open source community to create a de facto standard that you can sell software on top of. From your perspective, there’s got be commercial backing and people making money and getting paid. But do you ever run into that thinking that everything should be free and open? That basically software isn’t the “right” way to make money.

Mik: Yeah. And I think that’s a really interesting point. While I really like the dynamics of open source software development, I haven’t really had the luxury of subscribing to the free software philosophy. I’m more oriented to pragmatic open source. You touched on this a moment ago: there are very important things that open source enables in software development, including ease of collaboration. It makes it super easy for us to collaborate and exchange information. Open source helps us collaborate on and exchange intellectual property that makes sense to have in the Mylyn framework. The commercial-friendly Eclipse Public License allows us to sit down in a room with some developers from our partners, create a solution, and put it into Mylyn for our mutual benefit, without having to get lawyers or contracts involved. It eases collaboration not only for volunteers but for partner companies. This is in part why I’m convinced that frameworks and APIs are more effective being open source. The rapid adoption and evolution of Apache, Spring Framework, and Eclipse APIs attests to this. So I think open source is great for all these things, but in the end, as a tool builder all I’m trying to do is make people more productive, by making their work day easier, making them less stressed, and making it faster for them to get things done. What that means is that I just want to find the most effective combination of open source and closed source mechanisms to accomplish that.

Scott: There are also some people who believe everything is moving from closed to open, as a natural progression, but it doesn’t necessarily seem like that’s borne out. It seems more like there’s a progression from both sides toward a hybrid middle, with an open base and companies building proprietary stuff and adding value on top of it. IBM builds WebSphere on top of Apache. CMS systems and a lot of other systems have some kind of a community version that’s free and then there’s a for-pay version. Would you agree that maybe the best thing for users, the community, innovation, and moving a software product forward fast is this blend of an open source foundation with proprietary functionality built on top of it? That basically allows companies to drive the open source base forward, because they have a way to generate the revenue to pay people to work on it.

Mik: I think that kind of mixed model is a very healthy thing for our industry, because it allows companies to invest in open source without cannibalizing their business model. We’ve bootstrapped the Tasktop startup on revenues while investing a large proportion of our development efforts into the Mylyn open source project. The mixed model enables that, and it’s very rewarding for all involved. The fact that you have very talented developers who are bored working their day jobs, and who are contributing to all these open source projects as volunteers, to me, is amazing and I really like being engaged in it. It can also be a good hiring vehicle because it selects people who are fundamentally interested in the technology. On the flipside, open source can attract opportunists interested in padding their resume and being motivated by credit and not contribution, but we have found that to be the exception and not the norm. But for these concentrated efforts where you’ve really got to build up intellectual property, and you design and figure out how to deliver that, having a mixed model is amazing. You can both fund it and still leverage the collaboration benefits of the open source and the amount of bandwidth that you can get from early adopters.

Sean: We should probably watch the time, but is there something you think that’s really interesting around this conversation that we didn’t ask about?

Mik: I think it’s interesting to consider the various ways that we pay for the software we use. We were just chatting about free software volunteerism. But what we’ve noticed with Mylyn and Tasktop is that there’s a category of people who care about the mechanics and benefits of open source, but there’s also a huge category of people that just want to try software that’s free. They pay in various ways. Some of them pay Google with their eyeballs by watching ads. We try to get people on Mylyn to pay for the fact that they’re using Mylyn for free by having them comment, give us feedback, and give us patches. We’re always encouraging that. If they find something confusing in our documentation, we talk to them to update the documentation. I think we’re getting into this interesting mixed world where it’s becoming clear that the open source frameworks are a great delivery method, and a great way to collaborate. Now these different ways of paying are getting ironed out. We’ve got the mixed source approach that IBM is doing, as well as other models where you pay for web services built on open stacks.

You alluded to things like SugarCRM, which has a community version and a commercial version, which, I think is excellent. It stimulates investment by both larger companies and startups in open source. It means that we’ll have that much more in this commons of open source framework in the future for new innovations to come up, and it opens up the space for integrations, since open source tools are easier to integrate with. Mylyn and Tasktop would never have happened if not for the fact that IBM made a tremendous investment in playing the mixed source card by making Eclipse open source. It allowed us to leverage the internals of the IDE and the internals of the way that they integrate with OSes like Windows in order to deliver this new way of working. Duplicating that effort, or attempting to create our own widget toolkit like many web apps are being forced to do, would have meant that we would wouldn’t have had enough time to focus on our core competency, which is innovation.

Scott: Well, this has been a fantastic interview. Thanks for taking the time to chat with us.