Tasktop

There was more going on in San Francisco than the Bay to Breakers race this past weekend (May 18-19). The 35th International Conference on Software Engineering, the premier software engineering conference, also began and will run from May 18-26. ICSE, as it is known in the research community, has attracted more than 1000 people from 50 countries to the Bay Area for over a week of communicating new advancements and best practices in software engineering. Tasktop is a sponsor this year and will be participating in events such as the student-industry lunch, where 300 students will have a chance to exchange ideas with and hear about opportunities at sponsoring companies. With Tasktop’s current growth, we are eager to meet these high-caliber students!

But Tasktop has even deeper roots with ICSE. A fundamental aspect of Tasktop’s vision has always been to improve communication and collaboration amongst the people involved in software development so as to truly connect the world of software delivery. The initial step Tasktop took towards this vision was to embed the concept of a task into the IDE as part of the Eclipse Mylyn project. When Mik Kersten, our CEO, started the Mylyn project in the UBC Software Practice lab, the need for tooling to connect the IDE to common issue repository systems quickly became evident. Luckily, a connector that allowed issues from Bugzilla to be brought into the Eclipse IDE was available within the Software Practices Lab. This connector had been built as part of the Hipikat project . Hipikat recommends items from a software project’s history, such as past bug reports, source code commits and email messages, that might be useful to a developer currently trying to perform a task on the project. In essence, Hipikat serves as a memory of the entire project built from the project repositories so that it can answer a question that you might have asked someone at the water cooler if they had only not left the project. The starting point for many Hipikat queries is an issue or a bug. For instance, a developer may select a bug he or she wants to work on and ask Hipikat for similar bugs that have been solved in the past. As a result, Hipikat needed a means of having bugs in the IDE, which caused the initial development of a Bugzilla connector. Shawn Minto, who built the Bugzilla connector, is one of Tasktop’s most experienced software engineers.

On Friday of the conference, Davor Çubranić, who conceived and built Hipikat as part of his Ph.D. work at UBC, and myself, will receive the “Most Influential Paper 10 Years Later” Award for the paper about Hipikat. Our paper is receiving the award, as it catalyzed substantial work on recommenders for software engineering, some of which are finding their way into practice today. For example, more and more sophisticated code completion recommendations are finding their way into the Eclipse Java editor.

Hipikat’s name means “eyes wide open” in the West African language Wolof. Keeping your eyes wide open is as critical today for tackling the hard problems of software engineering as it was ten years ago. Each day, Tasktop strives to keep its eyes wide open when tackling the challenges that come with with connecting the world of software delivery. Will you be attending the ICSE Conference? If so, please tweet me at @gail_murphy.

On Friday, May the 10th, Tasktop released 2.7 for both Tasktop Sync and Tasktop Dev. This continues to demonstrate our desire to put out a major release every six months and a minor release every three months. This regular cadence helps manage scope and deliver value to our customers in a managed and controlled way. Version 2.7 was a major release with many new features, bug fixes and improvements, but I want to focus on two main themes.  The first is the release of our first PPM connector for CA Clarity PPM, the second is improvements to our IBM Rational Requirements Composer connector. Both demonstrate our continued desire to connect the world of software delivery by enabling different tools and disciplines to work from the same data and collaborate more effectively.

Support for Clarity PPM

For many developers, the world of the project office is an alien one, with its staff talking about investment portfolios, resource pools and demand management. The same can be said of the PMO when trying to understand developers who work in scrums and talk about CI and GitHub. But with the advent of faster delivery times and Agile methods, development and the PMO need to work together in more dynamic, flexible and aligned ways. That means traditional integration approaches, such as spreadsheets and email, need to be replaced with automated integration. This need led us to develop a connector for CA Clarity PPM, which enables the two teams to work together more effectively sharing work across organizational and tool boundaries. The development of this connector also reinforces our strong partnership with CA and demonstrated our support for CA Clarity Agile and CA Clarity requirements.

Building the connector has reminded us yet again that the technical side of integrating the process and data is often the easiest part. It also reminded us that getting agreement on how the artifacts flow between these two organizations is actually much harder. As we worked on the early version of the connector with a customer, it became very clear that though at the highest level the PMO and development had shared objectives, the reality of day-to-day operation was very different for the two groups. We learned a lot about how the PMO and Development can work together during this process. This learning will form the basis of a webinar titled ‘Connecting CA Clarity PPM with Development Tool Stacks from IBM, HP MS and more’,which not only will demonstrate CA Clarity PPM integrating with the development stack, but will also describe the integration patterns that make sense and the key decisions you need to focus on when building the integration. The best practices of integration continue to drive our investment in Software Lifecycle Integration, where we hope to codify and share these ideas.

Improvements to the RRC connector

As more and more people improve their requirements processes and start adopting tools like IBM RRC, it is clear that requirements can never exist in isolation and that integration is key to delivering software effectively. Requirements tools are great at improving the discipline of requirements, but without linking them to a broader ALM tool stack, the requirements start wrong and just get worse. The key to good requirements is flow and collaboration; flow, meaning that the requirements seamlessly flow between management, the business, development and test, and collaboration, meaning that every stakeholder involved has the ability to comment, discuss and more importantly disagree with the how and why a requirement adds business value. We at Tasktop are heavily involved in this dialogue and continue to improve our requirements connectors as we understand how this interaction plays out. For example, a key improvement in the 2.7 release is the ability to sync into folders between RRC and HP QC / ALM. For many organizations, a folder is more than a way to group large list of requirements; it actually includes some level of business semantics. By adding this capability, we now can share context across tool boundaries.  This is a great example of something that we learned from our customers and partners as we enable better requirements flow and collaboration with Tasktop Sync.

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

For the second year in a row, Tasktop has been named to British Columbia’s Ready to Rocket list.  This exclusive group is made up of 25 privately-owned companies in the technology and communications sectorwho are positioned for high growth in 2013.  A hundred semi-finalists are selected by Rocket Builders through open nominations, and from this hundred, only 25 are chosen to be a part of the final list. Lucky for us, Tasktop was deemed worthy.  As Reg Nordman, Managing Partner at Rocket Builders, said, “Each year when we choose the Ready to Rocket companies, we are looking for those companies that have best matched technical innovation with market opportunity. Tasktop Technologies is an excellent example of the right technology for the right customers at the right time.”

For us at Tasktop, being named to the Ready to Rocket list for the second time highlights the sustained opportunity we have in front of us and reinforces our excitement for what is to come in 2013.  It’s so fulfilling to see that outside groups have just much faith in our success as we do, and we’d like to thank the selection committee at Rocket Builders for acknowledging us.  As a bootstrapped business, we are proud of what we’ve accomplished so far; we experienced a 250 percent growth in 2012 with the help of our 50+ staff across two continents, and being recognized by Rocket Builders makes all our hard work even more worthwhile.  Tasktop is certainly “Ready to Rocket,” and we have great expectations for our continuing growth in the coming year.

Tasktop is always looking to add the best and brightest to our team, so contact us if you’re interested in joining a company that’s passionate about connecting the world of software.

Lets be honest. I dread the “What do you do?” question in a bar or party setting. If I ever have to go beyond the “business manager in a private software company” line when introducing myself, the reaction is one that, at best, is an “Oh…” More likely, the person just looks for the first opportunity to walk away. Even the “but… but… I was a professional blackjack player…” or “I helped make a really cool ebook app…” or “My daughter really loves baseball…” usually doesn’t salvage the day.

The real answer to the question of “What do you do?” is that I work for a company that provides an integration platform to connect up the tools and people that produce software from idea to coding to deployment. Our customers are some of the largest companies in the world, and in nearly all cases, they build software not for the sake of commercializing it, but rather as a means to solving a problem or driving a competitive advantage in their respective industry, from banking, to insurance, to healthcare, to retail, to manufacturing, to government. We’re helping traditional businesses turn into software delivery organizations. Cheers to that.

When you think of integration, its just not sexy. Period.

Even though we are participating at SXSW Interactive this week as a stop on the SXSW Startup Crawl, and our CEO Mik Kersten has a talk on Monday evening, the reality is that we just aren’t as cool (or as young, truth be told) as a lot of the folks who do social or mobile or cloud. We do know what those words mean but our lot is all about creating a new kind of collaborative infrastructure for software delivery. We are at SXSW because our US HQs are located in Austin and because of my love of the SXSW event, even though Tasktop doesn’t fit neatly into an event that I often joke is short for “SeXy SoftWare”.

I promised Mik that I would pitch his SXSW talk, so here is the pitch… We’re also here to demonstrate how crucial it is to create a multi-vendor platform for software delivery collaboration if we are to make the next order of magnitude improvement in our ability to deliver software, as Mik will outline in his talk Social Code Graph: The Future of Open Source. Seriously, it is a marriage of a geeky topic with cool visualizations, and I would encourage you to attend and experience some of Mik’s passion and boundless energy.

So, this blog is my feeble attempt to explain what we do and explain why it is important. I wish it was containable within 140 characters. I wish it was containable in some pithy one-liner that I could use at the bar that would result in me being the life of the party. Every time I get it to 140 characters, it sounds like some sort of marketing jargon. So, what we have at Tasktop is great business that solves a really big problem that still takes too many words to explain.

So, if your company produces software in any sizable scale, I’d encourage you to at least give this blog the ten minutes it takes to read, even if you aren’t directly or even indirectly involved in the production of software.

What is Integration?

When we talk about integration, we are talking about moving data from one system to another and keeping each system synchronized. That is exactly what we do at Tasktop. It’s all about the flow of information between the constituents who drive the creative processes around software delivery. We help companies automate the flow of information between all of their tools that are used in the production of software, ensuring that the right information is at the right place at the right time.

When you think about how software is produced, especially in large companies, it generally involves some hair-brained idea from a manager (I am a manager, so I feel comfortable making this assertion), some business analysts who have to convert that idea into a semi-sensible set of requirements, a product/project manager who must convert those requirements into a project plan, developers who get the pleasure of struggling to make it a reality, quality assurance personnel who figure out where they screwed up, and operations who determine why it won’t scale.

Generally speaking, each constituent above uses their own tools, often times from different competitive vendors. The various disciplines are often separated geographically, commonly with cultural and language barriers. The vendors are usually not interested in effective integration, as each is competing for grabbing as much of the software lifecycle as possible. Even if the products are from one vendor, they often are not integrated with each other. Adding fuel to the blaze, culturally, the different disciplines of software do not always get along. It is no wonder that, despite all of the great advancements in each silo, software projects fail or are delayed 24-68 percent of the time. At Tasktop, we do integration, specifically the integration to make information between the five disciplines of software delivery (requirements, development, testing, deployment and project management) flow between the various tools that each discipline uses. Whether you call it Application Lifecycle Management (ALM) or Software Development Life Cycle (SDLC), we are putting the “L” back into this business process of software delivery.

Why is Integration Important?

Why is moving data around between various systems something you should pay attention to? As we’ve been doing deployments of our Tasktop Sync integration solutions in enterprise situations over the past couple of years, we’ve learned that the data moving around is really just a proxy for the automation of the software delivery business process. As we kick off the deployments in our customers, we are often bringing the key representative stakeholders of the tools (e.g., QA and development) together for the first time to talk about not just their silo’d business processes, but more importantly, to talk about how the two (or more) disciplines should work together to build better software in a predictable and repeatable manner.

So what does this mean? The best way to think about this is by wondering what the world would look like when the software delivery process is not integrated. Over the past 15 years, we’ve seen each of the five disciplines focus internally as a silo. During those 15 years, each silo experienced tremendous innovations, such as Agile planning and development, Continuous Delivery, DevOps, functional programming languages, and test-driven development. The challenge was that as each of the silos optimized, the valleys between them grew ever deeper. Testers would often batch up all of the defects they discovered in a spreadsheet and share the defects every month or six weeks with the development team. Requirements were often not tied back to the activities that developers did and the tests that QA professionals ran, so a change to a requirement was often not caught. Reporting and analytics across the entire software delivery value chain was impossible without significant manual work. As more industries faced new regulations, increased reporting requirements, compliance from their stakeholders, and demands for more governance, the ramifications of not meeting these needs had real financial consequences. No matter what industry you are in, having an integrated software delivery chain will ensure higher software quality, faster cycle times for application development and delivery, and less rework.

Another reason why integration is so important is because it connects up different worlds. Over the past ten years, we’ve seen some pretty dramatic changes in the power of the individual. Whether it was populism driven by Apple devices being purchased by the individual and brought into the workplace, even though the individual had to pay for it out of their own pocket, or it was the freedom of inexpensive tools that an individual could easily purchase via a credit card (e.g., JIRA, Github or free e.g., open source ala Hudson/Jenkins, Git, Bugzilla, etc.), more and more software development had the inmates running the asylum. Even though Central IT groups or management had mandated the use of a particular tool stack or technology set, individuals were defying those mandates and going with the tools or devices that made them the most productive and effective in their jobs. So, one of the big problems that integration allows our customers to solve is to connect up the world of the individual, where the newest, coolest, most productive, least heavyweight usually wins the day, with the needs of the enterprise and what were viewed as heavyweight tools and technology that were trying to manage risk, gain visibility, ensure governance and compliance, and generally protect the organization. You can see one example of how Tasktop does this in the JIRA / QC webinar.

Hope to See You at SXSW or a Watering Hole Soon

Integration may not be sexy, but it’s now the main bottleneck that we as an industry have on scaling our collective ability to delivery software by 10x.

So if you see me out and about this weekend at SXSW, I am happy to talk about TechGirlz, or my kids, or Capital Factory, or DreamIt, or bootstrapping a business to 50+ people, or professional blackjack, but I hope you also ask me about integrating your software delivery stack. I promise I won’t scare you too much.

Putting the L in ALM – Making the case for Lifecycle Integration

I think everyone agrees that software delivery is not an ancillary business process but is actually a key business process, and the ability to deliver software faster, cheaper, and of a higher quality is a competitive advantage. But delivering software is difficult, and if you believe the Standish Chaos report, anywhere from 24 to 68 percent of software projects end in some form of failure.

Even the criteria for success has been questioned by many, as ‘on time, on budget, delivering the functionality requested’ can still mean software that fulfills requirements but adds no business value. Billions of dollars a year are spent on software development tools and practices in the desire to increase project success and reduce time-to-market. Each year, development, testing, requirements, project management and deployment roll out new practices and tools. Many of these additions bring value, thereby increasing the capability of each individual discipline. But ultimately, the problem is not the individual discipline; the problem is how those disciplines work together in pursuit of common goals and how the lifecycle is integrated across those disciplines.

It has been a year since I joined Tasktop, and during numerous customer visits and partner discussions, two things are very clear: 1. the landscape of software delivery tools and practices is going through a major change, and 2. to be effective in software delivery you need to automate flow and analytics.

The ever-changing face of software tools and practices

Add Agile, Lean Startup and DevOps to a large amount of mobile, cloud and open web, and not only do you have the perfect book title, you have all the ingredients necessary for a major change in the practice of software delivery. Agile and Lean encourage rapid delivery, customer feedback and cross-functional teams focused on delivering customer value. Mobile and cloud are changing the landscape of delivery platforms, architectural models and even partner relationships. Never before have we needed to build flexible development processes that encourage both feedback and automation. Imagine spending three months writing a specification for your next mobile application when your competitors deploy new features on a daily basis. Imagine not connecting your new sales productivity application to LinkedIn, where your sales people have all their contacts. Our development approach needs to not only include partner organizations and services but also deliver software at a much higher cadence.

Automation of Flow and Analytics (reporting) is key.

I have noticed a strange relationship between increased speed, reporting and integration. When you increase the speed of delivery, traditional manual processes for reporting and analytics stop working or become an overhead. For example, one customer spent two days compiling the monthly status report spreadsheet across development, test and requirements. This two day effort required meetings with numerous people and emailing the spreadsheet around for comment and review. When the organization adopted two week delivery sprints, this work was an overhead that no one wanted to endure. Now the company had a choice: drop the status report, or look to an automated solution. Because more frequent releases meant the need to collaborate better, they opted for an automated solution that connected the test, development and requirements tools, providing a report that described the flow of artifacts among these three groups.

The automation not only resulted in creating the report but also improving the flow between these different disciplines. Suddenly there was clarity as to the state of a story or when a defect should move into test. This clarity was avoided in the manual approach, which left large amounts of ambiguity. The report drove the creation of automated flow, which resulted in a better process, which then fed the report with better data.

That means there is a sixth discipline in software delivery

Lifecycle Integration is emerging as a key discipline for ALM. It provides the glue that enables the disconnected disciplines of requirements, development, testing, deployment and project management to connect. It unifies the process and data models of the five software delivery disciplines to enable a unified approach to Application Lifecycle Management (ALM).

Without integration, many of the disconnects go unrecognized, and the flow between groups is never optimized. The larger your software delivery value chain, the more pronounced the impact of these disconnects. Factor in external organizations, either through outsourcing, application integration, service usage or open source, and these impacts can mean the difference between not just project, but business success and failure.

Perhaps we in the software industry are suffering a bit from the ‘cobbler’s children syndrome,’ with integration being a first-class citizen in the traditional processes we have integrated for our business clients for years. But the time is right to apply these lessons and build a discipline around lifecycle integration for the practice of software delivery.

Having just returned from the fantastic ALM Summit in Redmond it is even clearer to me that there is a lot to talk about when discussing ALM. The event in Redmond is focused on the Microsoft platform, but the discussions were far broader. Technology impacts such as cloud, mobile and open source coupled with process changes driven by Agile and Lean Startup mean the very fabric of ALM is changing. The announcement of TFS and GIT working in perfect harmony is illustrative of this shift. But even after 3 busy days there is still lots to talk about, which brings me to the ALM Connect, an event that myself, the Eclipse foundation and a team of great people have been working on. The event, which is scheduled for March 25th through 28th in Boston MA has all the ingredients for an amazing conference.

Deep Dive Into Content

All the sessions in the program are great, but I would like to draw your attention to a few that caught my eye during the call for papers.

• Moving towards ALM 3.0 by Forrester Analyst Jeffrey Hammond. Not only is Jeffrey a great speaker, but always fills his presentation with lots of data that you can use back in the office. In this talk Jeffery is highlighting the major shifts in the fabric of ALM. Looking at the data this talk is based on we might see a redefinition of the ALM category, which is very exciting!
• What ALM knowledge you can expect from CS graduates by Gary Pollice, professor at WPI. The emerging skills crisis in software engineering is going to affect us all so I am excited to hear how you can better hire CS graduates and make them more productive. This talk also helps to remind us that ALM is more than just tools, but includes processes and people.
• Continuous Integration at Google Scale by John Micco, Google. CI has emerged as the lifeblood of modern software delivery, and on paper seems easy, but for the majority of large organizations with complex builds, heavy dependencies and nasty test environments building a workable CI environment is difficult. In this talk John describes how a very complex CI environment can be built and maintained in a very changeable business.
• Building Mylyn 4.0 by Mik Kersten, CEO of Tasktop. Mylyn has defined how Eclipse developers interface with systems of record such as bug trackers and project manager tools, but the underlying model has not changed for over 5 years. Mik is going to describe what needs to change to get Mylyn ready for next generation ALM.

Bring your boss to ALM Connect Executive Event

ALM Connect will provide a rich set of ideas for practitioners to take back to their teams, but without management support many of those ideas will never be implemented.

Above: EclipseCon 2012 ALM Panel with Mik Kersten, Dave West, Melinda Ballou and James Governor

Solving this problem was the motivation of running an Executive event on Wednesday the 27th of March. This event is aimed at decision makers and is by invitation only.

Content highlights include:

• Twitter and Github kick off the event talking about the future of ALM and how the next generation of software development is being undertaken. These presentations will show how you can marry innovation, rapid delivery and complex development teams into an Agile delivery capability.
• ALM in action case studies. Still working on the fine print, but we will have two high profile companies who are going to present their experience with ALM and how they are using ALM to form a competitive advantage. These sessions are aimed at telling all the dirty secrets of ALM, the motivation for adopting ALM and the reality of ALM in their companies.
• The user is the center: Apps in the world of engagement by Lee Nackman from HP. Lee has been involved in ALM for many years and was one of the executives responsible for IBMs involvement with Eclipse. In this talk Lee will describe how systems of engagement have changed the face of ALM and how that is only to get worse. I expect some sneak previews of the HP’s future ALM strategy in this talk.
• Agile 2.0 software development in the era of the social graph by Israel Gat Fellow at the Cutter Consortium. Israel a leading management light on ALM and the economics of software delivery will describe the social side of development. Describing how social graphs and other mechanisms can be used to better manage and enable software delivery.
• Scrum – Success ends with middle management by Ken Schwaber co-creator of Scrum. Having Ken, one of the drivers of the Agile movement at the event will add a level of Agile pragmatism to the proceedings. In this talk Ken will present the audience with framework for taking Agile to the next level, but be warned this path is not for the faint of heart.
• The future of ALM panel – This session includes Sam Guckenheimer from MS, Lee Nackman, Jeffrey Hammond and Mik Kersten on what the future of ALM looks like and how it will affect the audience. I will moderate, so expect an exciting and thought provoking session.

If you are interested in attending the executive day, or have boss who is interested then please let us know. You may also wish to view the Executive Day landing page, or the event announcement from the Eclipse Foundation for a detailed agenda. I can promise the event will be exciting, thought provoking and inspiring. It is rare to get so many leaders on ALM in one room and at one event.

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.

Well fortunately, there was no fiscal cliff (though the U.S. government did nothing more than my 4 year old son; it just kicked the can down the street) and somehow there was a day after even though the Mayan calendar just stopped. As such, I feel a little more comfortable writing a retrospective blog that is as much about the past as the future…

2012 was an eventful year for Tasktop. We kicked off 2012 celebrating our 5th anniversary. In this blog, I wanted to take a few moments to reflect less on Tasktop’s outwardly facing accomplishments that we highlighted in the press release and focus more on the behind the scenes aspects at Tasktop.

I truly believe that when we look back on 2012, it will be viewed as an inflection year for Tasktop.

Eclipse Mylyn and Tasktop Dev keep doing their thing. Driven by Android development and Asian programmers, Mylyn rode the wave of Eclipse adoption in 2012 and regularly sees 2+ million downloads per month. Tasktop Dev continues to make Eclipse and Visual Studio software programmers who use commercial tools (Mylyn is a great free choice if your development tool stack is open source) more productive.

2012 was the year that we validated Tasktop Sync as a viable solution for connecting the world of software delivery. Not only did we demonstrate the need for tools integration but also exposed how integration matters for process, collaboration and reporting. It’s been fascinating to learn how big a problem we have unearthed. With our Mylyn roots and our partner ecosystem, Tasktop is uniquely suited to address the challenges of tool heterogeneity which is ever-present and growing in the enterprise struggling to deliver high quality software in a timely manner.

As a bootstrapped company, we continued to grow steadily. We moved our corporate headquarters in Vancouver. We are thrilled about the new office because it allows us to create the team environment that is conducive to the innovation we are driving and the challenges we are trying to solve. We also opened an office in Austin, TX where our US headquarters are located and where many of our partners (CA, IBM, Micro Focus / Borland, Thoughtworks Studios, Smart Bear, etc.) and hopefully future partners (Planview, BMC, etc.) have a presence.

As we strive to do every year, we added some of the best and brightest young minds in the industry to our staff, and are proud to continue giving back to the educational system that has been so good to us as company through our active internship and co-op program. In addition, we added some grizzled veterans (I can’t say grey haired because some of them don’t have any hair) like Lance Knight, Dave West, Nicole Bryan and Jason Baldy. All of this has resulted in an organization that is inspired to solve a big problem, enjoys celebrating victories, has fun as a team, can be silly with each other, but has the organizational maturity to deliver high quality software for our customers and partners. At the end of the year, we added our 50th employee.

I am very proud of the work environment that we are creating at Tasktop. Its one thing to believe that we are balancing a fun place to work with the aspirations of a company trying to solve a really big problem; its even better when our staff and others in our community back that with recognitions such as BCBusiness Best Companies to Work for in BC and Technology Impact Award for Emerging Company of the Year.

We were also quite proud of our CEO and founder Mik Kersten who was named a finalist for the World Technology Award and a Business in Vancouver Forty under 40. We are thrilled that Mik is being recognized for his leadership and technical excellence.

We are excited about 2013 where you will see even more innovation and fun from Tasktop!

I never thought this day would come, but I can proudly announce that this fall I have joined the team at Tasktop! I am the 50th Tasktopian. My story started a long, long time ago when I was writing my first Java programs. At that time, I looked for a tool that would help me focus on my job without spending too much time on setup and javadoc reading. Eclipse had it all: quick fixes, content assist, fast search, syntax highlighting, you name it.

Years passed, and although my requirements have not changed much, my projects got bigger, the number of files increased tenfold, and I started to feel lost. This is when I discovered Mylyn (known as Mylar at that time), and used it to regain my programming efficiency. I have been a big fan of the tool ever since and can’t think of any other Eclipse add-on that makes as much of a difference in my everyday work.

In the meantime, I was lucky enough to start working on the Eclipse project itself. Becoming part of the open source community around Eclipse was an eye-opening experience. Watching all those smart people sharing thoughts and contributing patches, I finally understood why the tool is so great. I have been involved in multiple projects on the Eclipse Platform, including JDT, PDE, JGit/EGit and Orion, and have received commit rights to some of them, which is a recognition that I’m proud of.

Throughout my journey, I always held onto my motto that “to be the best, you need to learn and play with the best”. This is what prompted me to apply for a position at Tasktop Technologies. Now I’m proud to be part of the team,making the lives of thousands fellow programmers better, and I can’t wait to see how my journey with Tasktop will continue to unfold.