Atlassian is no stranger to the open source community. From the beginning, Atlassian has given back to this community by supplying our own code, supporting other projects by donating our software, and sponsoring Open Source User Groups.
Amber Taylor of MuleSoft recently contacted me, and was interested in providing us with an update on how they use Atlassian’s development tools. MuleSoft has been a happy open source customer since 2004, and are powering their entire open source community site (www.mulesoft.org) with most of Atlassian’s tools. When we caught up with their co-founder back in 2007, they had 15 developers, 650K downloads, and about 1K users. In only 3 years, they have grown to about 50 employees, 1.5M downloads and 2,500 production deployments! This piqued my interest, so I set up an interview with Amber and MuleSoft Software Engineer, Mark Griffin.
MuleSoft, formerly MuleSource, is a Web Middleware Company, providing enterprise-class software based on the world’s most popular open source application infrastructure products, Mule ESB and Apache Tomcat. With Mule ESB, Tcat Server and iBeans, MuleSoft brings an ideal combination of simplicity and power to today’s web applications. The open source community around Mule ESB is extremely active in contributing to the project. They put a lot of importance on enabling their community through the website, which relies on most Atlassian tools in the background.
How do you use our tools?
We use them on the Mule project itself and also community-contributed projects on MuleForge. We mostly use the products for what they were made for: JIRA for bug tracking, Bamboo for builds, etc. But, the product where we feel we are getting the most mileage is Confluence. We are using that not only for user-editable content, but also for our main content delivery system.
Which products did you start with?
We started out with Confluence and JIRA, then moved to Bamboo. We had FishEye before the Cenqua acquisition. Then, we started adding more products, and multiple installs of the products. Next, we were thinking about a hooking in an LDAP directory, and how that was going to be a lot of overhead. Then you guys came out with Crowd, which now authenticates more than 30K users.
How is JIRA being used?
Each MuleForge project gets its own JIRA project. We also have the Mule Community project which gets its own JIRA project and Mule Enterprise gets one too. JIRA is used for internal and external purposes. We have well over 100 projects on our public install. For mulesoft.org/jira, it is used for bug tracking and project management. We are currently on version 3.13 [current version 4.0].
Customizations and plugins?
We have custom permission schemes and custom field definitions. We are set up for our documentation writers so if there is an issue with docs, our writer is notified. It’s hard to think of all of the customizations these days, it’s grown so much!
For plugins, we have GreenHopper, the FishEye plugin and for a while we were using the SalesForce plugin. JIRA is light on plugins, Confluence is where we really went to town.
We integrate with Xircles which is a spin-off of the software that Codehaus is run off of. It’s a sort of project management tool, but at the development level. When you create a new project, it initializes its own SVN repository. It’s for development tool management and shares the same LDAP directory.
Advice to smaller companies interested in JIRA?
We love JIRA. It has scaled well for us. It’s stable with very few bugs. JIRA is the product we have been the most happy with. We would definitely recommend JIRA without hesitation. The memory footprint seems rather light for what it is – just all good things.
What do you use Confluence for?
We are on version 2.10 [current version 3.1] and use it for a couple of reasons. It’s the main content delivery system for our Mule ESB product. Each one of our products gets their own space. In addition to that, each MuleForge project gets its own dedicated space. We have more than 100, but less than 150 spaces. We did not have a wiki product before Confluence.
Regarding customizations, we use the Adaptavist Theme Builder. It gives us flexibility to make it look less like a wiki and more like a website. Originally, we expected Confluence to be more like a wiki where we would place content that users would edit a lot, but we ended up using it more as a traditional website with static content.
How did Confluence spread throughout your organization?
Our corporate wiki started out small and then expanded to different departments. That has worked out pretty well for us. At first, when it was just a handful of us, it was the one simple space of employee resources: ‘name’ and ‘contacts.’ At that point, we started to branch it out so each department got its own space and made sure it was permissioned accordingly. There is a small learning curve for Confluence. We give people the option to use wiki markup and HTML. We wrote a bunch of custom macros to make it even easier for people. That’s my favorite thing about Confluence—I like the simple syntax and user macros. We have fairly complex nested macros to not freak people out.
What would you tell a smaller company asking about Confluence?
It’s great for a wiki, but when you try to use it for a general content management system, it doesn’t scale as well as I’d like it to. In all fairness, I’m basing this off of the version we are running [current version: 3.1] and we are using it how it wasn’t designed: we probably have 10 or 20 times the spaces that others do.
How do you use Crowd?
Crowd is the middle-man of all of these. It has the caching feature that allowed us to integrate everything. We have an external and internal instance. We run JIRA, Confluence, Bamboo, FishEye and Jive Forums through Crowd. We are using Crowd as a delegated authentication over to our LDAP directory. It provides a great UI to manage those groups and, more importantly, it had nice handy connectors to hook in all the apps. We needed a lot of the caching for that.
Atlassian tools have been a huge time saver for us, both marketing and development-wise. We love the development tools, they work fantastic for us. We use Bamboo, not only to do snapshots of developer builds, but also publish with it. It’s crazy.
Thanks Mark and Amber!