Q&A with Mik Kersten, Mylar project lead
ZDNet: For someone who has never used Mylar, how would you describe what it does?
Mik: Today's enterprise applications and frameworks are composed of millions of lines of code. What the state-of-the-art IDEs have done is made all of that code instantly accessible. But when used on large systems, views and searches of the system will often contain thousands of elements. The result of this information overload is that developers often spend more time repetitively scrolling, searching, and navigating code than they do programming. The key intuition behind Mylar is that for any bug that we need to fix or feature we add, we only care about a subset of the system.
I'm in love. This is just too gorgeous.
What Mylar does is provide a new task-focused user interface that makes this subset explicit by automatically managing task context on your behalf. With a single click, you indicate the task that you're working on, at which point all of your programming activity for the task will start to form its context. Views of the systems are filtered to show only the elements within the task context, instead of being overloaded with thousands of elements. Changes are automatically grouped by task, and a test suite for the task is automatically generated.
Mylar also makes multi-tasking easy by allowing us to instantly recall the context of previous tasks, for example in the case where a bug is reopened. Collaboration is facilitated with the ability to share task contexts. The end result is that developers can focus on their programming activity instead of repeatedly searching for information and manually re-creating their context. [Continued on page 2...]
ZDNet: Mylar has been under development for over a year now. Can you tell us about what's been going on recently?
Mik: We released Mylar 0.6 along with June's release of Eclipse Callisto. That release was solid enough result in thousands of early adopters of Mylar using it for their daily work. It also provided an onslaught of invaluable feedback via bug reports, many of which were enhancement requests about improving the integration of Mylar's task management.
"Mylar" is:
-- Mylar web site
- An aluminized film used to avoid blindness when staring at a solar eclipse.
- A focused user interface used to avoid information blindness when staring at Eclipse.
For example, a key benefit of Mylar is that it brings all of the developers' tasks and bug reports into a single list, and provides offline access for the integrated repositories that include Bugzilla, JIRA, and Trac. Since 0.6, we have built on this to make Mylar's Task List replace the web browser and email inbox as the tools that developers use to manage tasks. When five new comments come in on a Bugzilla report while you're eating, with Mylar once you return from lunch you simply note the "incoming" arrow on the corresponding task, and open it to find the new comments unfolded and highlighted. So you instantly see what you need to read without clicking through notification emails in your email inbox and opening browser windows. And when you open the bug you don't wait on a slow server, because Mylar caches all repository task data locally.
In addition, we have done a lot of the little integration bits that provide big time savers, such as drag-and-drop attachments, linking of revisions to tasks, automatic commit messages, managing of perspectives with task context, and streamlined sharing of task context.
ZDNet: Can you describe the roots of Mylar? How did you get involved with it?
Mik: I created the Mylar project as part of my PhD thesis. Before I started my thesis, I worked on the AspectJ team at Xerox PARC and did the tools framework and IDE integration. I realized that while the benefits of aspect-oriented programming can be very substantial, the resulting reduction in code size is incremental. You're doing great if you're working on an enterprise application and you manage to get a code reduction of 20% from moving your crosscutting code into aspects. Or perhaps you get that same benefit without realizing it by having the Spring 2.0 Framework encapsulate the aspects for you.
But when you're working on a system that's a few hundred thousand lines of code, and building on frameworks that are millions, that 20% reduction still leaves you totally overloaded with information when you're programming. I realized that modularity improvements alone could not solve this problem, and that a limiting factor was the fact that the IDE was showing us the compiler's view of the system, and not a task-centric one. Along with my thesis supervisor, Gail Murphy, we figured out that the programmer's interaction with the system could be used to create a degree-of-interest weighting of the relevance of program elements to the task. This showed promise in revolutionizing the way that we use the IDE and having a profound impact on programmer productivity.
ZDNet: Mylar is rather unique in the statistical user studies that went into it. What kind of studies have you done and what did they show?
Mik: There were two key studies. The first study, of Mylar 0.1, was done over the course of a week on six developers in the IBM Toronto lab. We compared the developers' usage data before and after they used Mylar, and noticed that when their views were focused, they spent more time writing code and less time looking for the information that they needed to write code. But Mylar 0.1 only had a single task context model for the entire workspace, so both from our own bootstrapped use and from their feedback we realized that we needed to integrate support for tasks in addition to managing context.
"The most addictive Eclipse plugin ever."
We resurrected a Bugzilla plug-in that Gail's group had worked on previously, integrated support for task management, and presented the result at EclipseCon 2005 in order to get participants for a second user study that could determine with statistical significance whether Mylar's task context model made developers more productive. We released Mylar 0.3 on July 4th 2005 to the first 100 developers willing to participate in the user study, and 4 months later had enough usage data to definitively state that the answer is, yes, an explicit task context makes developers more productive. On November 4th 2005 we wrapped up the study and made the 0.4 release of Mylar publicly available from eclipse.org.
ZDNet: What lessons have you learned about open source / community development over the course of this project?
Mik: The key lesson is the enormous value of managing the bug reports that define how a constantly changing user community needs a new tool to work. A huge challenge with Mylar was that nobody had done anything quite like what we were doing, so we had to grow the UI in a very organic and agile way. We resolved almost 2000 bug reports leading up to version 1.0. The dozens of comments on some these bug reports embody the feedback and wisdom of hundreds of developers needing Mylar to support their work process.
As you can probably guess, part of the reason why Mylar has such advanced task management facilities is the amount of tasks that the Mylar developers have to manage. What we have also noticed is that integrated support for task context really helps tighten the feedback loop between us and our user community. For every bug that we fix, we attach the task context, and that in turn helps share the committers' knowledge with users, making it easier for them to contribute. This has also been a key enabler for us getting the Mylar integration to the point where it is with 1.0. We have applied hundreds of patches from contributors and integrators wanting to make Mylar work better for them. Constantly making efforts to lower the barrier to contribution has been critical in making a project with so few committers support so many users.
"I've been using Mylar for about a week now and I still catch myself giggling gleefully every once in a while."
-- Wayne Beaton
I also want to mention a more recent lesson I learned because it was a bit of a surprise. Eclipse.org has an IP review process that if not managed carefully by a project can slow contributions, especially when those contributions involve new library dependencies. However, with Borland's recent announcement that JBuilder 7 bundles and builds on Mylar, we have just witnessed the benefit of this process. Along with the Eclipse Public License, this process makes it easy for companies to build on our innovations and integrate them with their products, such as issue trackers and tool suites. We're excited about it because it moves us along our goal of getting the benefits of Mylar's task-focused UI to all Eclipse users.
ZDNet: Is there any corporate sponsorship or is it all academic / volunteer?
Mik: The Mylar project has not received any corporate sponsorship to date. The bulk of the work initially came from the validation needs of my thesis, and there is ongoing academic effort around Mylar because it provides a framework used by other research projects to conduct field studies and experiments.
My academic funding came from an IBM Centre for Advanced Studies fellowship and from the Canadian government's NSERC program, and I'm grateful for the fact that this funding allowed me to focus completely on the Mylar implementation and validation, and for Gail Murphy and the University of British Columbia Computer Science Department for setting up the environment that made this work possible. The Google Summer of Code program was also a help because it provided two open source "interns" to us last summer, and resulted in Steffen Pingel contributing Trac integration and earning commit rights.
Beyond that, Mylar has been a community effort driven by the passion and patches of users who have shared our vision of refactoring the way we work around tasks.
ZDNet: What makes Eclipse a good platform for this kind of work? Could you have done it in NetBeans or Visual Studio?
Mik: First, I think that the kind of competition that we're seeing between Eclipse and NetBeans is healthy, as is competition between Eclipse and Visual Studio. Eclipse's extensibility has made it possible for Mylar to be created without requiring changes to the underlying platform. When you consider that Mylar affects just about every part of Eclipse that the programmer interacts with, from the information displayed in views to the way that synchronization with the source repository works, this is a pretty incredible thing.
Having written AspectJ plug-ins for several IDEs I know that extending tools in a way that was not conceived of by the creators of the framework ranges from hard to impossible. This extensibility of Eclipse, driven by the excellent OSGi plug-in model and the very high quality modular architecture that resulted, demonstrates that Eclipse is well on its way to becoming the de facto platform for tool innovation. There is a very careful balance that the platform needs to play between supporting unforeseen innovation, and being rock solid in order to support all of the commercial tools built on it. Finessing this balance is part of the beauty of Eclipse. It enabled us to follow suit and ensure that our new interaction technology is seamlessly integrated, and meets the very high expectations that developers have of Eclipse.
"If you are a serious Eclipse user and are programming on large projects using Eclipse I strongly encourage you to check out Mylar -- it is a real killer application."
As is the case with any other platform, Eclipse needs to continue evolving to keep building on its success, and continue growing its frameworks and supporting additional extensibility. For example, the current user experience of a developer using both the CVS and Subversion support in Eclipse is a bit disjointed because the underlying framework has not yet encapsulated the common functionality. But the great thing about Eclipse is that it evolves to meet its community's needs, has an open and transparent feedback and planning process, and provides clear incentive for both users and vendors to contribute such improvements.
ZDNet: What do you have planned for the next release of Mylar?
Mik: One priority will be evolving our Tasks frameworks to address the needs of the growing number of integrators of Mylar who do not want to reinvent the wheel with task management integration. Mylar works best when it has rich integration with your task repository or issue tracker, so this is key to delivering the benefits of Mylar to every Eclipse developer.
Currently we provide out-of-the-box integration for projects using Bugzilla, JIRA and Trac, but there are dozens of issue trackers out there, and we look forward to seeing that integration happen as we move towards the Europa releases of Eclipse and Mylar.
In terms of the task context, we currently support the core Eclipse SDK, which means that the task context model understands the structure of files, Java code, and Ant and PDE XML. We also look forward to supporting integrators building on our Context framework to extend it to other tools and languages."This project is one of the most open and responsive communities I’ve experienced. It has definitely set an example for others projects to follow."
ZDNet: Any closing thoughts?
Mik: I would like to encourage users and integrators to get involved with the project. Community contributions have been a key part of our success to date, and have turned two developers into committers. Existing committers are all very pro-active about assisting and applying patches, and the directions that Mylar takes post 1.0 will continue to be determined by our growing community.
Resources: