We are starting up several projects right now at OpenPlans. As a first step, we are setting up project management infrastructure for each. You would think that being a 10-year-old software and media company, we'd have rock-solid, time tested, perfectly smoothed out techniques for managing our projects. The truth, as it often is, is a bit more complicated than that. Part of the reason is that we run a series of reasonably independent projects, that have started at different times, and have different needs. Some are existing open source projects that already have communities and tools in use. Others are more traditional client projects. Others are internal projects. And so on. Point is, we've never tried too hard to standardize, and our general philosophy is to use the tools that best fit the particular job. Since we spent a bunch of time debating our options and experimenting with tools over the past few weeks, I figure it's worth putting down on paper what we chose and why. Here's the stack we ended up settling on for one of our new projects, OpenBlock.
Time tracking: Tick
Why: We were looking for an easy way to track time against a set of high level budget items. Quick input of time sessions was key, as was keeping track of how our logged hours matched up to our budget. In the end, we chose Tick, primarily due to the slickness of their desktop widget. I was thinking that an IRC-based hour logging client built on any time tracking tool's API would be the way to go, but the Tick widget really is far better than that would be. Tick also has really nice budget progress indicators built in to the time logging widget. Notes: Tasks are duplicated here from our budget, and actual work tickets (in the public Trac) are kept separately. But since we're only tracking on a high level, that's fine for us. The Tick/Basecamp integration was surprisingly unhelpful. As of right now, it lets you automatically post time entries as Basecamp messages and lets you import time from Basecamp into Tick. The feature I really wanted was the ability to sync tasks between Basecamp and Tick, using the Tick widget to track time against Basecamp tasks. The other missing feature needed to make that actually work is task estimates in Basecamp, which currently aren't supported. Alternatives we considered: Harvest, FogBugz, Assembla
Client hub: Basecamp
Why: Basecamp has a nice, clean, friendly user interface, and makes it pretty easy for our clients to stay up-to-date and for us to share docs and to-dos. I've been a fan of 37Signals ever since I saw Jason Fried give a talk back in 2004, and I consider their book Getting Real to be somewhat of a bible. Notes: The Messages tool feels wrong, especially for those of us who spend a lot of time on regular mailing lists (only the top response is sent via email, so you can't reply in-line). Their shared document tool (Writeboard) is not well integrated. It would be sweet if they used Etherpad now that it's open source. We've found Etherpad to be one the absolutely most useful collaboration tools, and now that Google acquired it and Etherpad.com is shut off, we run our own internal instance and can hardly live without it. Alternatives we considered: Assembla, Google Groups. Apparently activeCollab is maturing as an open source Basecamp-like thing, but we didn't really explore it as we were looking for something we didn't have to maintain.
Wiki & ticket tracker: Trac
Why: We've been heavy trac users for many years, and our former coworker Jeff Hammel has written a lot of trac plugins. We also felt it was important to host the ticket tracker for this open source effort on a portable open source platform, rather than on a pay-as-you-go hosted service. Notes: Trac has a ways to go in terms of user interface (which I've hacked on a bit), but the platform is flexible and powerful. Alternatives we considered: Google Code, GitHub, Lighthouse
Mailing list: Google Groups
Why: Thanks in part to our resident in house open source process expert, Karl Fogel (who is currently working for O'Reilly and Code for America out of our office), we decided not to start a new mailing list and instead just join into the discussions already happening at the "EB Code" list -- this is the list created by the EveryBlock team when the code went open last year.
Code repo: GitHub
Why: We chose GitHub for its sociality and community. In the past, we're run most of our projects out of our own SVN, but are increasingly moving to GitHub because it's easier for people to find our stuff and participate that way. Alternatives we considered: our SVN, BitBucket
Project blog: Tumblr
Why: While we are huge WordPress fans and long-time users, we decided to use Tumblr for our team blog here. Primarily just to have one less thing to maintain, but also because we like how easy it is to post snippets, screenshots, and other short notes using Tumblr. Separately, we just started another group Tumblr blog at dataintoaction.org, and are enjoying it. Notes: There's not yet broad support for group blogs in the Tumblr theme ecosystem, but I imagine that will improve over time. Alternatives we considered: Posterous, our own WordPress. We almost went with Posterous, which has a more vanilla default template and better OOB group blogging support. But Tumblr's handy bookmarklet for quick posting won us back over.
A note on Assembla:
The stack we ended up with is actually quite similar to what we started out thinking we'd use. The big monkeywrench came when we started exploring Assembla, and realized that it did a bunch of the things we were looking for: issue tracking & milestones, estimates & hour tracking, mailing list, team wiki, code repo integration, and (way, way) more. It seemed like we'd be able to solve our client hub, internal estimating, and hour tracking needs with a single application. However, one issue got in the way of us using it: Assembla handles estimating reasonably well using it's Agile Planner view, but time estimates and hours are not well integrated elsewhere on the site (namely in ticket queries and in API). And on the flip side, important ticket filters aren't available on the Agile planner view. So, we couldn't get the view we were looking for in either case. But I think Assembla has potential -- it's a little rough around the edges, and they're trying to do a lot at once, but it's not bad. If I were them, I would open source the code and focus on hosting. As an open source project, I think Assembla could easily beat out other competitors (namely Trac), and people who want don't want to run their own would still pay for the hosted version. This is how Acquia and OpsCode run their businesses, around Drupal and Chef, respectively, and it seems to be working for them.
Takeaways:
The big takeaway is that there isn't one solution to rule them all, and that we should be at peace with a heterogeneous set of tools that work together for us. In the end, we realized that the biggest concerns for us were a really nice interface (critical for something you use all day every day), and solutions that were relatively low-hassle. While we are an open source organization in mission and practice, we don't always choose the open source tool, because in the end we need to focus on doing our work, not maintaining our tools. I think my ideal combination would be a hosted open source app, where we could deploy our own and hack to our needs if that made sense. Anyway, we're glad to be all set with tools so we can get to work!
- Loading comments...