Tasktop

Disjointed tools have inundated the application lifecycle. At its roots, tool diversity is a good thing. Over the past few years, it has transformed the way software is built via Agile methods, open source tools and differentiating vendors. But it has also wreaked havoc on the decade-old promise of Application Lifecycle Management (ALM). We need a new kind of infrastructure to deliver on that promise in a world where developers get to choose the tools that make them most productive. The time has come for an integrated lifecycle bus that allows information to flow freely between developers, testers, business analysts and administrators. This infrastructure will enable us to connect the best offerings in ALM in order to create a Lean Software Lifecycle, and implement a build-measure-learn loop that connects business idea to app store, and back again. We need a set of common data models and architectural patterns. Most importantly, we need to establish the common artifact that will connect the lifecycle. We are calling the category of infrastructure that will enable this Software Lifecycle Integration (SLI).

When outlined on a whiteboard or diagram, the architecture of today’s ALM stack resembles a half-eaten bowl of spaghetti, with meatballs corresponding to the various tools selected by stakeholders. We have two choices, either find a way back to the homogenous and single vendor solution of the 1990s, or embrace heterogeneity and come up with an infrastructure that provides end-to-end collaboration and traceability across best-of-breed tools.

Not long ago, we witnessed a similar transformation of the app dev stack. Once the services, databases and app server space enabled heterogeneity, the middleware category materialized and the Enterprise Service Bus (ESB) emerged, along with the new title of “Enterprise Architect”. History doesn’t repeat, but it does rhyme. It’s now time to create the role of the Lifecycle Architect, and to define an architectural framework for connecting the software lifecycle. Just as the notion of services was key to enabling the ESB, and file and documents abstractions were to sharing data, we now need an abstraction to connect the software lifecycle and to create a Software Lifecycle Bus. That abstraction is the social task.

Today Tasktop is a kicking off an effort to bootstrap the SLI discipline, with a series of whitepapers discussing the technical architecture, common data model, and technical tools. We are proposing the Eclipse Mylyn m4 open source project as a home for collaborating on a de facto implementation of the SLI data model, which will leverage what has been learned from the adoption of Mylyn, integrations that build on it, and new efforts around the open standards of Linked Data and OSLC. Later this week we are also launching an SLI integration patterns catalog, based on existing input from our customers, and open for all to contribute to. By the end of the week, with input from key thought leaders present at the ALM Connect subconference of EclipseCon, we plan to release a first draft of the SLI manifesto. To learn more and to participate, see:

	Whitepaper: Building the Business Case for Software Lifecycle Integration
	Whitepaper: Software Lifecycle Integration Architecture
	Software Lifecycle Integration landing page
	Eclipse Mylyn m4 Project Proposal Draft
	SLI Patterns Catalog Wiki (to come)

Learn more about SLI

January 17th marks the 6th anniversary of Tasktop’s inception, and has given me an opportunity to think about the past 6 years, and the next. All technological revolutions require a new kind of infrastructure. This decade will mark the shift to the software economy, with traditional companies turning into software delivery organizations. The problem is that, outside of ISVs who have glued together their own ALM processes, we’re not all that efficient at building software.

The generation before ours mastered building cars, managing just-in-time inventories of parts, as well as complex supply chains. And yet we’re still seeing software collaboration across companies and departments being done via spreadsheets and email threads, today’s equivalent of carrier pigeons. While the rest of the ALM industry sorts out the new generation of systems of engagement to make developers, Agile project managers and other stakeholders happy, Tasktop’s mission is to create the infrastructure that glues together this new breed of tools, with tasks as the new currency of planning and collaboration.

When staring out the window at our new Vancouver HQ, I often fixate on the orchestrated flow of cargo ships routing containers–the abstraction that has come to define the shipping industry. Rob Elves, co-founder of Tasktop, joins me in the picture below, as we were reflecting on our journey of the past six years. We validated the need for a layer of infrastructure between the developer and the various ALM servers by shoehorning it into the Eclipse desktop client and giving it a single and collaborative UI called Mylyn. That paved the way for our first commercial product, called Tasktop Dev, whose success was not just in laying our commercial foundation and revenues that drove our growth, but in allowing us to learn what a mess software development outside of the IDE really is. In our mission to connect the world of software delivery, the next step became overwhelmingly clear. A new infrastructure for connecting the software siloes within the organization, and increasingly across the chain of software suppliers, is now the bottleneck. Even the cars that previous generations learned to build so well now depend on dozens of software suppliers working together. Without automating the interaction between these suppliers in a way that supports collaboration and lean delivery across organizations, innovation is being stifled.

As Neelan reported in the Tasktop Year in Review, 2012 was huge for us with with 250% growth since our last birthday. A portion of the year went to thinking about what shape this new task “container” has in the software lifecycle. But it’s now clear that the problem is not the container, as the Mylyn model is nearly expressive enough, and our work with IBM in OSLC and W3C Linked Data is a good start to defining things like common query APIs. It turns out that the biggest gap is the lack of infrastructure for shipping this information between people and tools, and supporting the many previous attempts by each vendor in defining their own APIs specific to their specialization in the software lifecycle.

In 2012, Sync became the lifecycle integration platform of choice for numerous Fortune 100 companies. We got to learn what it was like to be building infrastructure and digging canals between vendors while becoming a mission critical component of the stack, which resulted in Sync’s transition to an enterprise-scale lifecycle integration bus. We’re looking forward to scaling this new kind of collaborative infrastructure in 2013, and making your software lifecycle as orchestrated as the flow of container ships through Vancouver’s magnificent harbor.

A room full of developers and students, cans of beer loosely scattered around the room, along with bags of chips, pop and pizza. It’s a setup that would make more sense for a party, were it not for everyone clustering around power cords and loud finger tapping of engineers ripping up their laptops.

Sticking to traditional hackathon culture, there was a whole lot of coding, lots of beer, and happy chit chat mixed with serious faces betraying some heavy problem solving, in a word: hackathon-fun!

In attendence: several experienced Eclipse submitters, students from SFU and UBC, and other Eclipse enthusiasts. Projects hacked on: JDT UI, Scripted, Orion and Mylyn (for project details see the wiki page).

It was great to have Ian Skerrett from the Eclipse Foundataion attend and hack away with all the others. Great many ideas were thrown around and many a bug got fixed. Newbies got to learn a lot about Gerrit & Mylyn and how to contribute to open source. Thanx to all who attended and made the night that much better!

See more photos from the event.

In Total Quality Management, the 1-10-100 rule states that prevention is 10x cheaper than correction, and 100x cheaper than failure in the field. We usually apply this principle to our thinking around defects and as a driver for continuous delivery and feedback loops. However, in much of the Agile discourse these days, the traditional requirement gets left behind.

Development has been transformed, from the bottom up by open source and inexpensive tools like JIRA, and from the project management level down by the Agile movement. But in large-scale software delivery involving very complex products and supply chains, requirements are the tasks that connect strategy to shipping software. The trouble is that the tools that we use for requirements management are completely disconnected from the modern Agile delivery process.

Consider a requirement to add a web service API to an app. Sounds great when expressed in Microsoft Word with direction from the CIO. After being passed to development, SOAP technology is selected on the merit of being present in other parts of the product line. A few developers comment on the corresponding user story that SOAP is inefficient and could cause serious CPU overhead, but both the business analysts (BAs) and the Ops folks are well out of the loop as they never log into JIRA where the discussion is happening. The solution is deployed, passes basic scalability tests, then after going into production it becomes clear that the SOAP solution will not scale to support the projected user base without a massive new infrastructure investment. So three months after the requirement was defined, the business analyst gets to realize all of this, learns a new acronym (REST) and another round of implementation is scheduled for the upcoming sprints. That’s the 100x cost scenario that we see all too often. Had the BA seen some of the comments in JIRA, a lot of waste could have been prevented.

This problem was partly addressed a decade ago with the Rational Unified Process (RUP), which created a homogenous Application Lifecycle Management (ALM) stack from requirements right down to development. But that approach constrained developers to the point where the Agile and lightweight ALM tool rebellion transformed the landscape. We now know that an efficient application lifecycle is capable of leveraging best-of-breed tools, with stakeholders such as Developers, Business Analysts, Project Managers and Testers working in the individual tools that make them most productive. Until today, only a few brittle point-to-point integrations existed between requirements management tools and the rest of the ALM stack. With today’s release of Tasktop Sync with integrations for IBM Rational Requirements Composer (RRC), IBM RequisitePro (ReqPro), CA Product Vision, and improvements to our existing integrations for HP ALM and QC Requirements Module as well as Accept 360, requirements are now a first class citizen that can span the lifecycle.

While the new support for sync’ing requirements is the biggest part of the story of our ongoing quest to connect the world of software delivery, there are many more highlights to the Tasktop 2.4 release, including major new features for ALM integration administrators such as a web dashboard for monitoring and IBM ClearQuest support. To learn more see:

• Tasktop Sync 2.4 New & Noteworthy
• Tasktop Dev 2.4 New & Noteworthy
• New CA Agile Vision and Product Vision Connectors
• New RRC Connector
• New ReqPro Connector

Every now and then you have a conversation that changes your view of the world. I’ve now had a dozen of those with one person, Dave West, in his role as Forrester analyst, VP, and Research Director. The common thread in our dialogue has been the need for application lifecycle glue that connects the software lifecycle stakeholders within the organization, as well as across the multi-company and increasingly open source based software supply ecosystem. Both of us realized that it would be more effective to make this vision a reality than to discuss it endlessly. So today, I’m thrilled to announce that we’ll be doing just that, with Dave West joining Tasktop as Chief Product Officer.

The very rapid growth that our products have seen lately is indicative of the need to look beyond any single tool in the evolving ALM stack, and consider the flow of information between the people that define the disciplines of the software lifecycle. Tasktop got to where we are today by placing a manic focus on the needs of the individual software developer, who was getting completely overloaded with the disconnected morass of ALM tools that failed to connect to the source code that defines delivery. That forced us to create a new model of social tasks that emphasized autonomy, transparency and integration across the increasingly diverse tool chain. With Tasktop Sync, our Task Federation has migrated from supporting Agile delivery on the developer’s desktop to connecting the rest of the software lifecycle in order to bring about a “Lean ALM”.

Driving a change in the way that software is built takes like-minded people filled with passion and purpose. Dave’s mission is to help people build software just a little bit better, and with our shared values, we expect that goal to materialize very quickly. In his role as an analyst, Dave has heard the software delivery needs and gaps of countless software organizations that build the products and services that we all rely on day-to-day. In his role as Chief Product Officer, responsible for transforming that need into our product vision and roadmap, you can expect Dave to accelerate our pace of customer-centric innovation even further as we work with our partners and open source community to connect the software lifecycle.

Read more in Dave’s post and Neelan’s post.

EclipseCon 2012 was my favorite to date, and I’ve been attending since the prototype—beers and demos at Thirsty Bear during JavaOne 2002. What made it so interesting was finally getting all the Eclipse devs in the same space as key folks from Agile and ALM. Developers are the engine of the software economy. But that engine is becoming part of such a complex ecosystem of vendors and open source that to scale software delivery, we need to break down organizational and departmental silos. We need to move towards what Forrester analyst Dave West has coined a Lean ALM. And that’s what my keynote was all about. Connecting devs to project managers, to testers, and eventually to @DEVOPS_BORAT.

Some have objected to my statement that Linus Torvalds’ bigger contribution to our planet is going to be Git, not Linux. Yes, Linux is everywhere. But Linux was a creative imitation, whereas I was focusing on the true innovations that are moving us towards the social code graph, and that’s precisely where Git fits in. Also, early in the talk I mention that Eclipse has gone from 1.5M to 2.5M downloads between January 2011 and January 2012. That’s monthly downloads, and with Vietnam surpassing Germany, a clear sign of the times.

Watch the keynote here, and I look forward to hearing your feedback and ideas.

For the past few years I have served on the Eclipse Board of Directors as an elected representative. I’m running again this year in the sustaining member category to help represent ecosystem of organizations that have made Eclipse successful, and to continue to refine the constructive dynamic that we have created in marrying commercial and community interests.

2012 marks the start of the second decade of Eclipse’s existence. I’ve been a committer on Eclipse for the past decade and have watched as an IBM initiative created a platform that now dominates the tooling space for professional developers outside working outside the VS/.NET stack. The leadership and innovation of Eclipse have created the modern pluggable IDE, innovated the code editing and navigation experience, fostered modern modeling technologies, and led the way in connecting the developer to the Agile, ALM and social coding movements. With the recent announcement of the VS 11 beta we’re reminded again that innovation can be cyclical. The first release of Eclipse from a dacade ago, visible above with its monochrome UI and toolbars, looks strikingly similar to latest version of VS 11 just announced (image from the Visual Studio blog).

While the strength of Microsoft is packaging a seamless end-to-end developer experience on a monolithic stack, the strength of Eclipse comes from the innovation driven by the large number of vendors leveraging Eclipse for gluing together the developer experience on heterogeneous stacks. For this next year of Eclipse’s evolution, both adapting the way that we build that tool stack in the social coding context, and improving ways to support our ecosystem of both community and vendor contributions, will be my priority if elected.

See my full vision statement on the Eclipse Board Elections page.

Five years ago, on Friday January 15th, I defended my PhD thesis on Focusing Knowledge Work with Task Context. The following Monday, January 17th, we incorporated Tasktop Technologies. Driven by the years of research that it took to prove that tasks are more important than files, integration is more important than features, and that focus begets flow, we embarked on a journey to bring to market a transformation in how we work and collaborate around software.

Our journey and passion have been fueled by our customers and our open source community, as to date we have not taken any external funding, and instead embarked on what’s more recently been defined as the Lean Startup approach to building a company in an Agile and customer-centric fashion. Bootstrapping, we have doubled in revenue and nearly doubled in head count each year since our inception, and now support over a thousand customers and over a million open source users. Working closely with our ISV partners, the Eclipse community and open source ALM projects, we are proud to be one of the key contributors defining the future of ALM.

In addition to the opportunity to be a part of a transformative endeavor, what’s guided our vision is a manic focus on the needs of individual software workers. Mylyn and its commercial counterpart, Tasktop Dev, materialized because the growth in complexity of software and the fragmentation of ALM tools were bringing our and our fellow developers’ productivity to a halt. Tasktop Sync was born out of the same need to give other stakeholders such as testers, project managers and business analysts, a connected and collaborative view on the software delivery process. With our focus on integration, our goal is to empower developers and other stakeholders in order to advance ALM to support the rise of the software-powered economy.

We want to take this birthday moment to thank all of the customers and partners who have made it possible for us to do what we love, which is to invent the future of ALM and to strive for our goal of doubling the productivity of software developers and managers. We hope you like the next round of innovations that we are hard at work for launching in 2012, which will be a definitive year for software, for ALM and for Tasktop Technologies.

This Friday is the submission deadline for the Agile ALM Connect sub-conference of EclipseCon. This new conference fills a gap that many of us have noticed in the conversation around Agile, ALM and developers. The “developers” part of the equation is often either missing or an afterthought. Even though developers were the root cause of the Agile movement, the discourse around Agile tends to focus on project management related methodologies. Application Lifecycle Management (ALM), perhaps by virtue of the word management being part of its acronym, has a legacy of neglecting the core need to make developers empowered and productive. While end-to-end approaches like the Rational Unified Process (RUP) had end-to-end traceability, they treated developers as an implementation detail, and as a result, have been relegated to history books. In this new age of ALM, we need to make sure that we do not make the same mistakes again. The Agile ALM Connect conference is the place to have the conversations needed to bring together the latest developments in open source, Agile, large-scale ALM, and to get developers back to the center of the discussion.

Ten years ago, I got involved with Eclipse as one of the first non-IBM committers, which has given me perspective on the way Eclipse first disrupted and then evolved along with the application development landscape. By way of efforts like EGit, Hudson/Jenkins, Tycho, and the umbrella of Mylyn projects, Eclipse has since become the leading driver of innovation in moving the developer to the center of the ALM picture. Other IDEs and development platforms are now starting to emulate the dev-centric ALM transformation that Eclipse started five years ago. From this transformation, a new set of open source frameworks were created and now broadly adopted. As a result, the ALM projects on Eclipse have come to lead the connection between the developer and the Agile plan, deployment destination, operations team, requirements, and quality management.

At the Agile ALM Connect conference we will be charting the course for the role of the developer in ALM, while connecting the organization to the new breed of open source, Agile and devops technologies. Unlike conferences focused on methodologies, we are interested in the full spectrum of approaches, ranging from tools and automation to people and practices. If you have ideas to share on how the landscape of Agile, ALM, and application development should evolve over the next decade, consider joining the conversation.

For submissions and information see the Agile ALM Connect Conference homepage

A year ago at SpringOne 2010, Spring founder Rod Johnson announced a new technology called “Code2Cloud” during his opening keynote (skip to minute 56). Since that announcement, development of Code2Cloud has continued at a rapid pace, with a growing community of private beta users. The ideas and technology behind Code2Cloud have become an underpinning of how we see the convergence of ALM and cloud and a key building block of our vision for a more integrated and developer-centric ALM stack, outlined at a high-level in the following talk.

Many of you have been asking when Code2Cloud (or as some knew it, Cloud Foundry Code) is going to be made publicly available. Today we are announcing a key milestone on this longer-than-expected journey. Tasktop has now been tasked by VMware to bring Code2Cloud to the open source community. Tasktop’s services division has been the delivery partner for the project and Tasktop will continue to maintain and evolve Code2Cloud for the early adopters of the closed beta. Although we haven’t yet determined the specifics of how, when, and where Code2Cloud will be made available in open source, or for that matter the name of the project when it is open sourced, we are committed to making the project available in Q1 of 2012. Code2Cloud will be available via a community and commercial-friendly open source license (either Eclipse Public License v1.0 or Apache License v2.0).

We are announcing this change in the project structure because as with Eclipse Mylyn, we see a successful Code2Cloud as being built on an open and inviting charter for both individual and commercial contributors wanting to leverage the Code2Cloud frameworks and tools. We will work with our existing partners and community over the coming month to define a structure and charter for the project. We encourage any interested parties to contact us at partners@tasktop.com. We believe there are tremendous opportunities for ALM vendors to participate in and leverage Code2Cloud as an on-ramp to their initiatives and to get a step ahead in the move of the deployment destination to the cloud.

Over the past year, Code2Cloud has grown to become a developer-centric integration platform architected to connect developers to PaaS deployment destinations by way of the ALM stack. It supports CloudFoundry and builds on existing tools such as Hudson/Jenkins, Git and GitHub. It also provides a Bugzilla-compatible but cloud-centric issue tracker intended to connect the running application, CI and SCM tools to the developer’s desktop, and unifies services such as authentication via OAuth. A key opportunity that we see now is in making Code2Cloud even more agnostic of the ALM stack and in delivering its integration and Cloud deployment support to the wide variety of open source and commercial ALM tools available today.

If you have ideas or questions on bringing Code2Cloud to open source please post here. If you want to get involved in discussing the structure of the open source project please email partners@tasktop.com. For more see: http://tasktop.com/c2c