A conversation with Ross Mason, co-founder and CTO of MuleSource
- San Francisco
- Open source ESB software
- # of JIRA users
- # of JIRA issues
- 1,700; 80% closed
MuleSource is a leading provider of open source infrastructure and integration software. Co-founded by the creator of the Mule project, the company relies heavily on JIRA and Confluence to ensure visibility into the MuleSource development process and facilitate collaboration within the Mule developer community.
First of all, tell us about MuleSource and how it evolved from an open source project to a commercial venture.
I started the open source Mule project in 2003 out of frustration with what I call integration "donkey work." Previously, I had been working for an investment bank to architect an early ESB (Enterprise Service Bus) solution that integrated seven different systems. It took about a year and a half to come to fruition, in part because it was a challenge to find available technologies. There were proprietary integration solutions out there that didn't meet our needs for building an unobtrusive, light-weight solution, and there wasn't anything in the open source realm either.
Eventually my curiosity about finding a better way to overcome that integration "donkey work" led me to create Mule, an open source platform for integration. I first released the open source project in 2003, and the community quickly snowballed as more and more Java developers became involved.
In 2006, hundreds of thousands of downloads later, we founded MuleSource to further the development of the product and create new support and services options for the large enterprises using Mule in production.
Together, Confluence and JIRA have improved productivity 10-fold in terms of managing a distributed team of developers, tracking issues and fixes, surfacing documentation and knowledge effectively, and managing over 100 code modules.
— Ross Mason at MuleSource Inc.
So adoption was pretty quick. How many developers are in the Mule community now?
Yes, it cascaded very quickly once we released version 1.0 of the product. We currently have 15 core developers and over 1,000 open source users and developers who report bugs and submit fixes. There have been more than 650,000 downloads of the product and 5 million page views so far.
Why did you choose JIRA and Confluence to help run Mule development?
Actually, I worked at Atlassian on version 1 of Confluence, so the wiki was an obvious choice. I wasn't using an issue tracker when I started the Mule project, but once I was introduced to JIRA I immediately recognized its value and asked Atlassian for an open source license. Since then (2004), both products have played vital roles as we've scaled our documentation and bug fixing to meet the needs of the growing developer community.
Together, Confluence and JIRA have improved productivity 10-fold in terms of managing a distributed team of developers, tracking issues and fixes, surfacing documentation and knowledge effectively, and managing over 100 code modules. JIRA has an unparalleled capability to do that with such ease. It's a nice, clean solution from a technology standpoint. And the ease of use of Confluence allows the community to contribute to the documentation and keeps everyone up to date, no matter where they are in the world.
Let's talk about JIRA. Who uses it and what are they using it for?
Our developers use JIRA to track issues in the Mule product and to manage their work queues. I use it to track the health of the project. And the overall community of Mule users uses it to contribute not only bug notifications, but also fixes.
So you use JIRA both as an issue tracker and a conduit for open source contributions?
Yes. Even though we're a commercial company, we still run development of our product as an open source project. One thing JIRA provides is a community environment where people can actually see what's going on with the project and get involved in some way.
JIRA is also the hub where all of our core developers, about 15 people in 7 countries, can work together. We have a very distributed core developer team, and JIRA gives us that one-stop place for communicating about what everyone is working on, what's in their work queues, and what progress they're making on issues. And it gives me a full tracking environment — a complete picture — of what's going on with the project engineering at any given time.
JIRA gives us a one-stop place for communicating about what everyone is working on, what's in their work queues, and what progress they're making on issues. And it gives me a full tracking environment — a complete picture — of what's going on with the project engineering at any given time.
— Ross Mason at MuleSource Inc.
How has your use of JIRA changed since forming the company?
We're trying to utilize it more and more in our day-to-day work. We've even mandated best practices such as, "No code should be committed to the source repository unless there's a JIRA issue attached to it." The reason for that is to make sure that every commit has some sort of description and tracking behind it. Then we can link between JIRA and Subversion, which is very nice from a development standpoint.
We're also working on customizations to link JIRA with Salesforce.com and potentially to our customer portal. We'd like to be able to correlate customer information, like contracts, with issues in JIRA.
You're also using Confluence. How are you using the wiki and what inspired the look and feel?
We use Confluence mainly for our documentation, which is currently about 500 pages. The Mule project had the same look and feel for years. When we formed MuleSource, we wanted to change it to make it more aesthetically pleasing and we also wanted people to know right away that something had changed.
With Adaptavist's Builder we were able to design the wiki to follow our main website. You can hardly tell when you're looking at our actual website and when you're looking at a Confluence page.
Confluence was also an obvious choice for our intranet.
How are Confluence and JIRA integrated?
We link closed JIRA issues with the corresponding release notes in Confluence. We're looking into using Crowd for single sign-on with JIRA and Confluence as well as our customer portal and Salesforce.com application.
We're also building a Mule forge that will be using JIRA, Confluence, Bamboo, and Crowd.
How has JIRA and Confluence impacted the success of Mule?
JIRA and Confluence have played a very important role in the overall growth of the Mule user community — they really help to manage a big project when you've got very limited time. It started out as just me, and it's grown to more than 650,000 downloads and a very active community of users today who submit bugs and fixes in JIRA and add to our documentation in Confluence.
When we were raising venture capital, our backers were quite interested in how one person could manage a project of this size. They were impressed with the fact that with the right tools, JIRA and Confluence, it didn't take a large team of people to manage a lot of productivity because we could share pieces of work with the community. The collaboration and communication between all these different people is key to the success of an open source project.