Tasktop

Agile development is at a crossroads. Practices hardened around small teams of motivated enthusiasts are now being deployed at scale in the enterprise. Average professional software developers, far from the Scrum rock stars or Kanban aficionados, may remain inspired by their Agile training for a couple of months. Then the next release crunch comes, and too often the Agile process is perceived as yet another source of overhead that keeps the developer from coding. Agile practices which have not yet become engrained, even though they are recognized as beneficial, start to fall by the wayside. User stories are not broken down into tasks until the end of a sprint, release frequency drops, the Agile project tracking tool is only kept up-to-date at the insistence of the project manager masquerading as a ScrumMaster. The software development process is once again driven by managerial needs rather than those of the self-organizing team.

The unintended consequence is that the Agile process has degraded into a project documentation methodology. While managers who architected the large-scale rollout scramble to adopt even more cutting edge Agile and Lean practices to address these problems, upper management becomes concerned that they now have even less visibility into the development process than they did with waterfall. Arguments are made that teams’ velocity has increased, but the benefit is outweighed by the overall loss in predictability and increasing developer discontent. At this point, the expected ROI of Agile is looking more like a realized loss.

The frequency of stories like the above is increasing with the growing number of early adopters of Agile at scale moving beyond the initial honeymoon phase. For organizations scaling their Agile deployments into the thousands, it is not be feasible to train and motivate thousands of employees to do Agile as it is “meant to be done”. But complaining that developers are not doing Agile right is akin to telling iPhone 4 users that they’re “holding it wrong”. To scale to large enterprise, a new work process has to be encapsulated with tool support that embraces the individual contributors doing the actual work. To date, Agile vendors have done a very good job providing project managers and product owners with planning and tracking tools. However, the primary creators of project deliverables are software developers, and they have consistently been an afterthought in most Agile solutions and deployments and are in the process of being disenfranchised.

The crux of the problem stems from the inherent need for large scale adoptions of Agile to be mandated by management. Consider the previous technologies that followed this trend. The Unified Modelling Language (UML) seemed like a great way of getting business level requirements discussed as part of software design. Heavyweight Application Lifecycle Management (ALM) tools from a decade ago promised to transform the software delivery process. Both saw a backlash from developers who knew all along that they reaped more benefit more from lightweight tools that embrace coding and collaboration.

This decade-old backlash against heavyweight and management-driven ALM tool deployments was part of the inspiration for the Agile Manifesto’s call for “Individuals and interactions over processes and tools”. If we keep heading in the current direction of ignoring the need for tools that bring developers’ programming activity into the process and that provide them with a concrete and visible benefit to their day-to-day coding, we will witness the same kinds of failures with Agile that we saw with ALM tools. We have slid far enough down this slope that in 2011 we will start to witness both major hiccups and outright failures among early adoptions of Agile at scale.

To address this necessary move of Agile from early adopters to enterprise pragmatists, tools that focus on individual developers needs are the critical “last mile” of the Agile deployment. We need look no further than the Toyota Production System (TPS), the precursor of the Lean manufacturing trend which did much to inspire Agile development, for guidance on the role that software production tools need to play in the process. The TPS consists of three interlocked elements: the philosophical underpinnings that define what we deliver to the customer, the managerial culture that defines how teams collaborate, and the technical tools that get things done. Developer tools are as primary to Agile software production as assembly line automation is to cranking out Toyota Prius automobiles. The existing focus on the ALM and above layer needs to be extended down to the Integrated Development Environment (IDE).

Coding, deployment, source control, and continuous integration tools must be integrated as a key pillar of the Agile development process. The knowledge formed around development activities needs to be captured and linked within the plan and product backlog. User stories need to be automatically connected to commits, and the developer’s workspace focused away from the system as-a-whole and onto the task-at-hand. Developers need to be given powerful and efficient tooling which gives them a window into their part of the Agile plan and connects their workspaces to the delivery process as a whole. To avoid the backlash of a thousand developers complaining that the changes imposed by an Agile rollout are getting in their way, we need a new focus on the final and most critical gear in the Agile deployment—the developer’s workbench.

In the past year, the Application Lifecycle Management (ALM) space was one of change, innovation and confusion. Those of us answering surveys on change management and issue tracking solutions had a whopping 100 answers to select from. Heterogeneous and multi-vendor ALM stacks became the norm. Agile development was everywhere and helped in popularizing esoteric Japanese management terms with the common developer. On the open source front, buzz around distributed version control and social coding grew, and in November we saw the launch of regular episodes of HBO-worthy drama around Hudson. To help developers from going insane in this rapidly evolving landscape, Mylyn was promoted to a top-level Eclipse project providing an ALM interoperability framework and tools. With open source, Agile, cloud deployment and DevOps trending in 2011, the ALM space is poised to become as action packed as the Java app server space of yesteryear.

Over the next 10 workdays I will post a prediction per day on what to watch for in the coming months, starting with tomorrow’s:

Prediction #10: Agile adoption continues its managerial rise, developers get annoyed and cause a backlash

The Application Lifecycle Management (ALM) space is hot, rapidly evolving and fragmented. Over one hundred task and change management solutions are available. Significant fragmentation is also seen in source control, continuous integration tools, build systems and issue trackers, many of which offer similar feature sets. Agile rollouts are altering the development process and favouring lightweight tool sets. While ALM ISVs stake their ground in various flavours of “Agile ALM”, open source tools have shifted the landscape even further by taking the market lead in many ALM categories. These developments are great drivers of both imitation and innovation in the ALM space, the end result of which has been countless options for software development teams.

For the enterprise, the sheer number of options has resulted in the spread of the heterogeneous ALM stacks. Organizations large and small are spending an inordinate amount of time creating, configuring and integrating disparate ALM tools in order to provide some semblance of traceability across their development stack, let alone across functions such as QA and DevOps. At the same time, Agile and Lean methodologies are being tested at scale within large organizations. While most of us buy into the value that Agile promises, some early adoptions of Agile, especially those rolled out to thousands of developers, are teetering on the brink of backlash. There are two problems compounding the risk.

The first problem is that of forgetting the developer. A fairly common occurrence, as most companies don’t believe they can make money selling to developers. This has become a chronic condition of ALM tools that have focused management and traceability in a way that ignores where coding work is being done. No arrangement of fancy charts and task boards will help the organization know whether the product is on track if developers are not deriving benefit from breaking their work down into user stories and tasks.

The second problem is the lack of integration between disparate ALM solutions. ALM vendors compete against each other and want to bring as many customers as possible to their stack, which makes cross-vendor integrations an afterthought. In addition, open source projects have little interest in interoperating with the large and heavier weight ALM solutions in use at large organizations. The solution to this problem used to be simple: get your entire ALM solution from a single vendor. But in part due to all the innovation that we have seen from open source and smaller vendors, for most organizations this option is long gone, and while striving for ALM stack unification continues to be a goal, the reality is often best-of-breed heterogeneity.

The recent wave of consolidation in many major industries e.g., banking, telecom, bio-tech, and technology, further exacerbates the problem when trying to integrate systems of companies who have heterogeneous ALM stacks. Usually the choice comes down to continuing to operate development teams independently or abandon one of the systems in favour of the other thereby creating massive loss of organization knowledge in the abandoned legacy system.

Put these two problems together and you have a recipe for failure in your organization’s Agile or ALM deployment, or at best a huge waste of developer time. Agile provides teams with additional autonomy and removes the kind of predictability and transparency that organizations were accustomed to with waterfall. When working in all its glory, Agile increases the velocity at which business value is delivered and is a huge step forward from the previous status quo. But it all breaks down when your average developer, who is not an Agile aficionado, is given tools that don’t integrate with his or her coding workflow, and then told to manually track progress in a separate systems. Developers complain, their managers lose visibility, the organization then reacts by implementing band-aid integrations between their IDE, the Agile project tracking tool, requirements management tool, in house or team-specific issue trackers and various SCM tools. The organization then grows its own ALM integration team, but lacks the expertise or ISV and open source project relationships needed to create a solid solution, and the result is marginal ALM and tool stacks, annoyed developers, tremendous waste and loss of the promised ROI from Agile.

At Tasktop, we see a constant stream of requests from organizations handling these two problems internally and needing to bring sanity and productivity to their ALM stacks. The rapid success of the Eclipse Mylyn project that we created is due to the fact that we focused so heavily on the developer’s experience with ALM, creating the task-focused interface and the de facto standard ALM federation framework in the process. While Mylyn has transformed the productivity of countless open source and individual developers, today’s release is a major milestone in our mission to bring these benefits to the enterprise.

Tasktop Enterprise 1.8 includes new support for the most requested enterprise ALM integrations: HP Quality Center & ALM, version 3 of the IBM Rational C/ALM stack and Microsoft Team Foundation Server. Our new set of ALM integration offerings represents long-running collaborations with HP, IBM and Microsoft, convergent evolution of our open source frameworks and their web services APIs and deep integrations between the Tasktop tools and the ALM servers they build on. Developers now get Eclipse Mylyn-based tool support for using the HP, IBM and Microsoft ALM tools, the productivity benefits of the task-focused interface, as well as interoperability with the other ALM integrations we have created including Rally, ThoughtWorks Studios, VersionOne, Accept 360, CollabNet, Perforce, Polarion and Atlassian. The solution is forward looking, as Tasktop Enterprise will also embrace new developments in ALM such as the upcoming release of our Code2Cloud, our partnership with The SpringSource division of VMware, as well as new open source integrations that we’re working on for Git and Hudson. We are also announcing today that we are an HP Gold Partner and a Microsoft Visual Studio Premium Partner in addition to our Ready for Rational Certification being updated to v3.0.

For the developer, Tasktop provides a kind of Microsoft Outlook collaboration environment for their Agile and ALM systems. From within the Tasktop plug-in for their Eclipse-based IDE, or from the standalone Tasktop desktop application, developers can collaborate, get instantly notified of priority changes, and interact with their team. All of the ALM systems they use are seamlessly integrated and provide a unified user interface supporting the entire best-of-breed ALM stack. Thanks to the task-focused interface, one-click multitasking™ and workspace focusing, there is an immediate benefit of reduced information overload and provides an immediate productivity boost that comes from developers explicitly “activating” the tasks that they work on.

For the organization, the developer’s task-focused workflow means that ALM artefacts get automatically linked and connected by virtue of task activation. For any defect or user story the developer works on, a change set is created and tracked. Time spent is tracked automatically, but in the developer’s control as not to trigger “big brother” concerns. Task contexts automatically track all code and resources accessed as part of a task, so that expertise is captured, creating a knowledge base of the software’s evolution and storing that in the existing change management or task tracking tool. Links between previously siloed repositories are provided using Tasktop’s cross-repository linking features, which make it possible to connect defects tracked in an open source tool like Bugzilla to requirements tracked in HP Quality Center. Cross-repository synchronization can also be deployed, which leverages our task federation framework to provide facilities such as on-demand synchronizations of defects between IBM Jazz/RTC and HP Quality Center. The Mylyn APIs can additionally be extended to connect to in-house and custom ALM systems. In other words, no matter what your ALM environment and existing or upcoming deployment of servers, Tasktop provides both the developer tooling and the federation layer needed to make developers happy, productive, and successful with your current and future Agile ALM deployments.

Learn More

		Read the Tasktop 1.8 Press Release and the eWeek article
		Watch the Tasktop for HP Quality Center(QC) video
		Watch the Tasktop for Rational Team Concert (RTC) video
		Read about the Tasktop Microsoft Team Foundation Server (TFS) Connector

The productivity of the software industry is defined by developers, and the productivity of developers is framed by the programming languages, frameworks and tools that we use. On the language front, the past decade has brought stabilization, with statically typed object-oriented languages such as Java and C# becoming entrenched in the enterprise, and dynamic languages finding their niche. While language evolution continues in an incremental fashion, it is continuing to bring significant but diminishing returns. In contrast, the past decade has brought about a major evolution on the framework front. For example, first the dependency injection and then annotation-based REST support of Spring have made a much greater impact on how the average developer builds applications than the pending addition of closures for Java will provide, necessary as that may be.

Beyond frameworks, one of the most fascinating developments in developer productivity over the past decade has been in the area of tools. The IDE has become entrenched, Agile has come of age, and tools for planning, collaboration and application lifecycle management (ALM) have become the hotbed of innovation.

The application landscape that defines our work has changed as well. Only recently did debuggers and build tools manage to catch up to the needs of app server runtimes to provide the ease of deployment that we had with Smalltalk three decades ago. Enterprise application deployment is in the middle of yet another fundamental transition, with cloud infrastructure bringing about the next major shift in deployment architecture.

Code2Cloud Architecture

Cloud deployment will provide fundamental benefits, but as we saw with the move to app servers, development tools need to catch up with the new cloud technologies. In the meantime, without new innovation on the tools front, developers would again be burdened with constant administration and configuration of their builds and runtimes during the transition. We are all capable of setting up and administering VMs, configuring continuous integration tools to talk to deployment destinations, or hooking up issue trackers to SCM and testing tools. This can even make for a fun break from a long debugging session. The problem is that we are spending way too much time doing this busy work, and each second spent on manual configuration is taken away from what we ultimately love to do, which is creating interesting applications. Just as the success of Spring and JBoss demonstrated how important it was to evolve the framework along with open source innovations around the application runtime, it is now time to bring together the evolution of the framework, application lifecycle tools and cloud deployment.

A year ago, I was driving with Rod Johnson through the hills east of Palo Alto and we were mulling over this problem between hairpin turns. We devised a plan to combine the best open source innovations of Spring technologies on the framework side, with the progress that has been made on the application lifecycle tools front around Mylyn, and the latest in virtualization and cloud technology from VMware. By the end of lunch in La Honda, our deductive powers heightened by the adrenaline from the drive, we had what looked like a design for the next wave of developer productivity tools. It would give the developer a full turnkey experience while providing the level of control and flexibility of open source. We then created a secret open source effort to provide the missing link between the developer’s desktop and the cloud. Yes, “secret open source” is something of an oxymoron, but this next step in developer tools was a significant enough departure to require a year of focused development during which we put these technologies together and created this new layer of innovation. The result of this collaboration is the VMware Code2Cloud offering.

Code2Cloud Workflow

In summary, Code2Cloud builds on Mylyn, Hudson, Git and Google Web Toolkit (GWT) to provide a turnkey application hosting experience. Sign in from STS, start the wizard, and with a click your application, source code, tasks and continuous integration builds are hosted. Fix a defect in the SpringSource Tool Suite (STS), and a Hudson build is automatically kicked off. When successful, the build is automatically deployed at your deployment destination of choice, such as VMforce. The running application is then connected back to your application lifecycle tools, and monitoring technologies automatically create defects with the code related to runtime problems captured as a Mylyn task context.

In addition to the benefit that this will provide to application developers, Code2Cloud will provide a new platform for innovation around the intersection of application lifecycle tools and cloud deployment. The solution is designed from the ground up to be extensible and integrated. On the extensibility front, it provides the most thorough set of REST APIs for Mylyn-based IDE access, and even the GWT-based web front-end is entirely built on these APIs. In addition, we are providing full support for the Open Services for Lifecycle Collaboration (OSLC) web services specification on which Tasktop collaborated with IBM. The entire solution is open source, ensuring that developers extending the solution are free to innovate and not limited to the inherent limitations of API boundaries.

On the interoperability front, as you would expect from Tasktop’s involvement, Code2Cloud is architected to support a very broad range of ALM offerings. Want to access your sources for an existing open source project hosted on GitHub? Just add it your Code2Cloud configuration. Want to use IBM Rational Team Concert for planning tasks in Code2Cloud, or link Code2Cloud tasks to defects in HP Quality Center? Just install Tasktop Enterprise to get access to our full ALM interoperability suite. The goal of Code2Cloud is not to create another ALM suite, but to provide an innovative platform and core set of application lifecycle tool functionality designed for cloud deployment, while supporting the broad range of ALM solutions already in use.

Code2Cloud Extensibility

Until today, application development and application lifecycle management tools have been disconnected. The innovation of Code2Cloud will redefine the connection between the developer’s desktop, the lifecycle management tools and the running application. In the video below you’ll see one example of the functionality this enables, with captured context from Spring Insight automatically percolating from the running application to the developer’s desktop. This is only the start.

Learn more on SpringSource’s Code2Cloud page or sign up to hear about future announcements related to Code2Cloud.

Over the past decade, an increasing portion of the innovation in application development has come from the Application Lifecycle Management (ALM) space. ALM tools define the development process, collaborations, and interactions that capture how an application evolves over time. Agile has come of age, ALM systems are now broadly deployed, and developers are using an ever growing range of communication technologies. Partway through this maturation of ALM, a gap formed between the ALM tools and the day-to-day development that was happening in the IDE. Mylyn filled this gap and bridged between the tools that we use to build software and those that we use for collaborating with our team and for planning the software’s evolution.

Today, the Mylyn committers are pleased to announce that the project has entered the next stage of its breadth and maturity, and has been promoted to Eclipse top-level project status. Top-level projects represent key areas of Eclipse functionality, such as the Web Tools Platform (WTP) for enterprise application development, or the Modeling Project (aka EMF) for model-based development. Also see Mike Milinkovich’s post on this announcement.

The Mylyn project is keeping its short nickname, but extending its charter to become the place for all Application Lifecycle Tool support that integrates with Eclipse. The mission of the project, listed along with the Project Charter is to provide:

		Frameworks and APIs for Eclipse-based task and Application Lifecycle Management (ALM).
		Exemplary tools for task-focused programming within the Eclipse IDE.
		Reference implementations for open source ALM tools used by the Eclipse community and for open ALM standards such as OSLC.

This development presents new collaboration opportunities in the open source and ALM space, a new set of integrations and features for users of Eclipse, and new opportunities for the growing ecosystem of Agile and ALM vendors building on Mylyn. The community won’t be waiting long for the initial outcomes of the increased diversity and scope of Mylyn. For example, upcoming support for continuous integration (CI) tools like Hudson is in the works and code review tools are on their way. Here is the initial layout of the project structure.

Tasks

		Bugzilla Connector: Mozilla Bugzilla bug tracker integration
		Trac Connector: Trac ticket tracker integration

Context

		Java Bridge: Context management for Java development with JDT
		C/C++ Bridge: Context management for C/C++ development with CDT

SCM

		EGit: The new top-level project is proposed as a new home for EGit/JGit
		CVS Connector: Task-based change set management for CVS, depends on team.cvs

Builds

Hudson Connector: Continuous integration access for Hudson

Reviews

		R4E: The reviews tool leverages the above integrations, and does not require a separate server integration, just a compatible Tasks and SCM integration
		Task-based Reviews: Lightweight code reviews shared through task repositories
		Gerrit Connector: Gerrit code review integration for Git repositories

Docs

		WikiText: Wiki-based markup editing for popular dialects
		RichText: HTML/XHTML/RTF markup editing

The following interview, recorded at the JAX 2010 conference in May, discusses the background for the project restructuring that laid the groundwork for Mylyn’s evolution into a top-level project. For those interested in more background on how Mylyn fits into the ALM space, there is an insightful podcast from Dave West and Jeffrey Hammond that discusses Agile, ALM and the role of Mylyn (at the 4 min and 45s mark).

Mylyn got to where it is today with over 900 contributions from non-committers made from countless patches, typically enhancements contributed by those wanting to add or extend existing functionality to their work process. The restructured top-level project builds on this success by supporting independent leadership for each of the sub-projects, while providing common framework projects a convenient place to collaborate on making common APIs. Tool sub-projects, such as WikiText, will continue to retain their own branding and manage their subset of the ALM community, while they collaborate with the other sub-projects on frameworks and APIs. We look forward to growing the amount of participation and collaboration around Mylyn, and continuing to help make Eclipse the leading IDE tool platform. Please let us know if you would like to get involved: http://eclipse.org/mylyn

Last week I stumbled on a tweet that questioned whether Tasktop was an “Obsession with integration or new paradigm of working?” The answer is both. The tricky part in bringing about a fundamental simplification in the way that we work is providing an incremental transition to the new paradigm. For the past year, our focus at Tasktop has been on expanding the ecosystem of Mylyn ALM integrations needed to get the benefits of the task-focused interface into the hands of the majority of developers using Eclipse. With this release, over 50 integrations exist and the majority of ALM solutions used by Eclipse developers are Tasktop Certified, including 70% of those covered in Forrester’s Agile Wave.

Tasktop’s developers and farm of interop testing servers are working tirelessly for one reason. To bring about the migration away from file, folder and search-based navigation, which does not scale to the volumes of information that we deal with today, to the focus and control that comes from the task-focused collaboration paradigm. While a few key connectors are still in the works, with Tasktop 1.7 we have crossed a threshold in the reach of integrations building on Mylyn. We have measured that more than half of enterprise developers’ time is wasted on constant interruption recovery and context switching. By integrating all of your tasks into a single Task List, anchoring of your collaboration around those tasks, be it file, comment, email or Twitter based, and then automatically focusing and restoring the context of your source code, files and web navigation, Tasktop eliminates all of that waste.

Bringing about this fundamental change in the way we work is impossible to do in isolation. During the past year of the Eclipse Helios release train, we have worked closely with both Agile and ALM partners such as Rally, VersionOne, ThoughtWorks and CollabNet, as well as leading application development vendors such as SpringSource/VMware, to ensure smooth integration between application development, deployment and lifecycle management tools. In the features listed below, you will also notice the results of projects that we undertook in order to make Eclipse be a better platform for this next level of ALM integration that we are driving. We worked with IBM to define OSLC-CM 1.0 spec for REST-based interoperability of change management tools and brought that implementation into Mylyn. We worked with Microsoft to enable Eclipse to leverage new features in Windows 7, the results of which you will see in our contributions to the Eclipse Platform’s New & Noteworthy and the Tasktop RCP screenshot below. Not wanting to neglect our users on Mac OS X, we also resolved one of the biggest performance problems in the Cocoa port. For the Eclipse Foundation, we created the Eclipse Marketplace Client, which uses the simple install technology that we moved into the Eclipse P2 project earlier this year. Finally, we restructured the Mylyn project to bring in new contributors bringing about the next phase of ALM integrations ranging from continuous integration support to code review tools.

It has been a busy 12 months since the Galileo release, and Tasktop 1.7 marks the third major Tasktop release in the past twelve months. For the full details on this release see the New & Noteworthy documents, and for some key highlights see below.

Twitter integration for the task editor

Tasktop 1.7 introduces Twitter integration for all Mylyn connectors. Developers can now view all tweets related to a task and quickly broadcast the currently active task. This is useful for promoting social collaboration and awareness in community-driven development, such as open source projects. While Twitter provides public social communication, integration with tools such as ThoughtWorks Studios’ Murmurs provides project-specific social communication.

Task Editor with Twitter section for social collaboration

IBM Rational Team Concert Connector

Tasktop’s new Rational Team Concert (RTC) Mylyn Connector provides the task-focused interface and Agile task management capabilities to developers using RTC. Developers are now able to instantly resume their coding session when switching work items, automatically track and update time estimates on user stories, and link between RTC and more than 50 ALM integrations provided by the Mylyn ecosystem. The RTC Connector is included with Tasktop Enterprise and available now through Tasktop’s Early Access program. Contact us to evaluate the RTC Connector in your environment.

IBM Rational Team Concert Mylyn Connector

Updated connectors

Tasktop includes the leading Mylyn connectors, and Tasktop 1.7 includes key enhancements to connectors such as IBM Rational Team Concert and ClearQuest, ThoughtWorks Studios Mingle, VersionOne, Perforce, Rally, JIRA and Bugzilla.

Eclipse updates for Microsoft Windows 7

The Eclipse 3.6 Helios release includes enhancements for Windows 7 developed by Tasktop in collaboration with Microsoft. These improvements benefit all Eclipse users on Windows 7 including developers using the IDE and end users who run Eclipse RCP applications. One of the notable enhancements is the ability to display task repository synchronization progress in the task bar, and create and activate tasks from the task bar in both the Eclipse-based and standalone Tasktop application.

Windows 7 task bar with synchronization progress indicator and Tasktop actions

Managed Connector Install

Connector install, update, and compatibility are all managed by the Tasktop application. Regardless of what commercial or open source integrations you have installed, Tasktop Certified tools are guaranteed to interoperate with each other and with your vendor-supported server install. This provides seamless interoperability no matter how diverse your ALM stack is, and ensures that you always have the latest and most compatible version of Tasktop, Mylyn and relevant connectors installed.

Managed Connector Installation Dashboard

New task list presentation

A key new feature in Mylyn 3.4 is the redesigned scheduled presentation, which now serves the purpose of showing what’s most important when working with a large Task List. Important tasks appear near the top based on when they are scheduled and whether they have unread changes made by colleagues or outgoing changes such as draft comments. Be sure to try the presentation with the Focus on Workweek button enabled if you are using scheduling, as an additional benefit is that it does not duplicate tasks, since tasks that show in a container will not reappear in a container below it.

New task list presentation reduces overload

		Read the Tasktop 1.7 press release
		See more new features and enhancements
		Download Tasktop 1.7

Each year the Eclipse Foundation holds an election to vote in board representatives for its committers and sustaining members. If you represent one of these member classes you have one week from today to cast your vote. I’m running as a sustaining member representative and my vision is below. Voting uses a single transferrable voting system, so be sure to read other candidates’ positions before voting.

Vision

Eclipse has reached a stage of maturity that enables Sustaining Members to play a primary role in driving the direction of Eclipse. As Sustaining Members, we represent the largest volume of the Eclipse membership. In 2010 our impact on Eclipse and the value we receive from participating are poised for substantial growth.

I’ve been closely engaged with both the technology and the business aspects of the Eclipse ecosystem since the outset in 2001. I’ve worked directly with many Solution Member companies and watched some Eclipse business models flourish while others have failed. Starting a successful company around Eclipse has given me a pragmatic perspective on how to participate in the platform while growing both product and service revenues on Eclipse-based offerings. As a Sustaining Member representative, my duty will be to apply that knowledge to help make your Eclipse-based efforts successful.

Succeeding in Eclipse means striking a balance between the member, committer and user communities. As board representative, my priorities will be to:

		Facilitate reaching users: Marketing in a vendor-neutral open source ecosystem can be far from obvious, and reaching the very broad Eclipse user base is needed for both the commercial success of members and of Eclipse as a whole. I have been closely involved in improving the install story for Eclipse solutions and the upcoming Eclipse Marketplace client. These efforts will provide the next generation of opportunities to get your solution into Eclipse users’ hands.
		Lower the barrier to engaging with projects: With product releases and other pressures, too often the step of getting directly involved with an Eclipse project that you build on does not make the cost/benefit cut. But not getting involved has the longer-term cost of incompatibilities and overhead. Lowering the bar for direct participation will provide members with better access to the collaboration and contributor community that make Eclipse a great open source ecosystem. On the Mylyn project we have had over 800 bugs and feature requests resolved by community contributions. I will use my experience of making this work for Mylyn to help lower the overhead of participation with existing projects so that similar benefits are accessible to more members.
		Listen to members: My job will be to represent your needs on the board, and I will work with the other representatives to actively seek out feedback from all Solution Members. I helped make the needs of individual committers heard as a committer representative on the Eclipse board, and will ensure that your needs are represented in discussions and decisions made at the board level.

About the candidate

Dr. Mik Kersten is the CEO of Tasktop Technologies and lead of the Eclipse Mylyn project. Mik is a popular speaker on Eclipse at conferences in the United States, Germany, and worldwide. Highlights of Mik’s contributions to Eclipse include:

		Creator and lead of the Eclipse Mylyn project (since 2005)
		Active member of the Eclipse Architecture Council (since 2007)
		Elected committer representative on the Eclipse Board of Directors in (2008/2009)
		Only Eclipse evangelist to be voted a JavaOne Rock Star (2008 and 2009)
		Only Eclipse content author on the top authors of the decade list of IBM developerWorks Java
		PhD in Computer Science from the University of British Columbia that lead to the invention of Mylyn’s task-focused interface (2006)
		Co-creator of the Eclipse AspectJ and AJDT projects (2002) based on his work creating of the first Aspect-Oriented Programming (AOP) tools, Xerox PARC (2000)

Related publications

		Symbian Blog: Mik Kersten on Transparency
		Tasktop Blog: Growing open source ecosystems: the install story
		Tasktop Blog: Tasktop working with Microsoft to improve Eclipse on Windows 7
		How Software is Built: Interview with Mik Kersten (highest ranked in series)
		Tasktop Blog: Tips on paying for free software
		Tasktop Blog: Platform for Innovation, Part 1: Openness & Modularity

Read more about Mik Kersten on Wikipedia.

The Mylyn JIRA Connector has been developed as part of the Eclipse Mylyn project since 2006 (Bug 109905), when Wesley Coelho and I met in a Vancouver coffee shop and decided to start collaborating on an idea for a startup that involved extending Mylyn’s open source integrations to commercial tools. A year later Wesley became one of the first employees at a new company called Tasktop Technologies, the connector took off, saw steady community contributions, and Mylyn’s reach was extended to JIRA users. Later in 2007 we kicked off a collaboration with Atlassian to improve the JIRA Connector, which in 2008/09 led to Tasktop working with Atlassian to create the initial Atlassian Bamboo and Crucible connectors, now part of the Atlassian Connector for Eclipse effort hosted on studio.atlassian.com. The time has come to merge the two codebases of Atlassian’s Eclipse integrations, and Atlassian has asked that the JIRA connector move to studio.atlassian.com.

According to Atlassian, the decision migrate the source code to their own infrastructure was driven by a desire for greater operational efficiency. Both the implementation of the Connector for Eclipse and the APIs in Atlassian’s server products are evolving, and hosting all these projects in a unified infrastructure enables faster development and more frequent releases of new and improved functionality. The Atlassian Connector for Eclipse will continue to be open source and distributed under the EPL. Anyone can view full project activity and download the full source at https://studio.atlassian.com/browse/PLE. Currently, all committers to the Atlassian Connector for Eclipse are either Atlassian or Tasktop employees, but Atlassian is working to allow others to commit new functionality to the code base.

Mylyn has grown from two integrations to over four dozen, and is playing a driving role in developers’ adoption of Application Lifecycle Management (ALM) and Agile collaboration tools. Having a connector hosted as part of the Mylyn project used to be vital due to the friction of finding and installing Eclipse extensions, and the JIRA connector got very broad exposure. But with our introduction of the Mylyn Connector Discovery feature in last year’s Eclipse Galileo release, it became trivial for users to install Mylyn connectors wherever they are hosted. Also thanks to the discovery mechanism, the move will be transparent to users of the integration.

For users of Tasktop and Mylyn, the main concern is the availability of a high-quality connector. One of the most important aspects of Mylyn’s architecture is that it provides a unified user experience across all integrations, since the majority of the user interaction is handled by the Mylyn framework. Atlassian has provided assurance that they will contribute to the Mylyn framework as part of increasing their own resources behind the integration, which will help ensure that the integration evolves along with upcoming changes in Mylyn. An expected benefit of the move is that some of the shortcomings of the integration that stem from JIRA’s SOAP APIs, such as the lack of support for custom fields and workflows, will be addressed more quickly with all of the code hosted and supported under one umbrella. Tasktop’s relationship with Atlassian continues, and the JIRA connector remains part of the Tasktop Certified program that ensures usability and ALM stack interoperability.

Mylyn’s goal is to provide a framework for Eclipse ALM integrations and to support an ecosystem of extensions. To that end, we have aimed from the start to provide reference integrations to open source tools, starting with Bugzilla. The JIRA integration was the exception as JIRA is closed source, but has been very popular with open source developers due its use in some open source communities such as Apache. The move of the JIRA connector restores the clear split between Mylyn’s reference integrations to open source repositories, hosted on eclipse.org/mylyn and the very the broad ecosystem of integrations with closed source tools. This will help focus the resources of the project on the core framework and open source integrations, while mechanisms such as Connector Discovery and the Tasktop Certified program ensure easy installation and the quality of the connectors that developers need to get the most out of Mylyn.

Open discourse brings conflicts out from behind closed doors. A while back I was involved with an open source conflict that degraded technical discussions to power struggles. I looked to Bjorn Freeman-Benson and Mike Milinkovich the help resolve that conflict. This week, countless eyes were peeled on Planet Eclipse as a very public conflict arose between the two of them.

Open source passions often transcend organizational and professional boundaries. That’s what makes someone bored with their day job contribute to Eclipse on evenings and weekends. It’s what makes someone like Bjorn continue to be invested in the success of Eclipse long after he has moved on from his job as the Director of the Committer Community.

Mike, Mik and Bjorn at EclipseCon 2008