FogBugz, JIRA, and Wasabi
Prashant Deva (Hacker News, Reddit):
Both Atlassian and FogCreek started off as bootstrapped businesses. However, Atlassian is clearly the winner even though it started long after Fogcreek. I have seen how Atlassian went from underdog to beating Fogbugz.
[…]
It was very easy to run into an install of Jira on large open source projects, especially before Github became big. It served as huge validation and you ended up already trying the product before you even started a formal ‘trial’ for your organization. (Not to mention it also boosted Atlassian’s SEO).
[…]
Fogcreek invented their own language. This meant they couldn’t use all of the ecosystem and amazing tooling around Java, which Atlassian was able to take advantage of. Not to mention they had to spend enormous resources maintaining their own compilers and editors, and of course all new hires had to be trained on Wasabi.
[…]
Fogbugz did do a few things well though. It was super easy to create bugs. And it also supported hierarchical sub-tasks, something which Jira still doesn’t fully support.
However, anything beyond the basics and you start seeing the holes in the features.
Jira won because it was not opinionated. You can use it however you want. FogBugz had the philosophy to make bug entry super easy above anything else. Jira will let a manager define new custom fields and make them all compulsory. It perfectly fits how manager at big companies think.
FogBugz was designed for smaller collegial teams of people that wanted to work together effectively and needed a clean and simple way to track issues using the smart workflows that small, professional teams like to use.
It was remarkably successful and profitable from 2000 to today. We’ve never stopped working on improving it, but we also have never abandoned the market of small collegial teams of smart people.
By contrast, Jira was designed as “Enterprise Software” with features to help managers impose specific workflows on teams. Selling Enterprise software is a lovely, profitable business and Atlassian has great success selling to large organizations who ignore FogBugz, but it’s the opposite of what I wanted to do.
First, I find the premise that FogBugz “lost” a bit odd. It unquestionably never achieved JIRA’s ubiquity, but it still exists, Fog Creek still exists, and the money FogBugz generated Stack Overflow and Trello. If that’s a failure, then I would love to have another one of that scale.
[…]
They undercut us on price for the one market segment we couldn’t afford to match. This is the single biggest factor. Atlassian figured out pretty quickly that they could charge practically nothing for JIRA licenses for 10-person shops, and then make it by having a massive step-up for enterprise licenses. But nearly all FogBugz customers were ten-person shops or less; charging $10 for a starter pack would’ve murdered our income.
They had a functioning sales team; we had only a marketing team (consisting entirely of Joel). The parent article is incorrect about this. I don’t care what you want to call the team; Atlassian had people on staff who built relationships with managers at tech companies. This meant that they were able to land a lot of those enterprise sales that Joel’s blog wouldn’t reach. If you want to get 10-person shops, Joel on Software is great. If you want to get 200-person shops, you really need someone building up a relationship with managers from day one.
[…]
Our Unix on-site version sucked a lot of resources. This is different from Wasabi (I’ll come back to this in a second), but supporting our on-site Unix installations routinely took 20% of our entire FogBugz dev team, and, at its peak, could take even more. This hurt our development speed, especially compounded with our lower resources.
What Atlasssian’s called its ”pre-sales” team was entirely reactive. If you called them they’d have someone who could answer your questions about what the products did, but that was about it. If you asked them for a deal or a discount because you were a big company, they’d politely direct you back to the pricing page on our website. After-sales there was an advocacy team who would occasionally call random customers to ask what we could be doing better, and who would email to remind you your maintenance was about to expire.
[…]
For the vital first five years, JIRA and Fogbugz had diametrically opposed product strategies. Fogbugz was a tightly focused product that eschewed customization in favor of presenting how Fog Creek believed an issue tracker would provide the most benefit for a team of developers. JIRA from day one wanted to be all things to all people: there was no deeper strategy than “listen to what our customers want and give it to them.”
So as Fog Creek got this base of loyal customers who bought into the product’s vision, Atlasssian got… everyone else. And everyone else was more people.
I still think what you’re describing as pre-sales counts as a sales team. Fog Creek didn’t have a real equivalent; sometimes support would answer questions, and sometimes our SMTPs (management training program), and sometimes developers, and sometimes our office manager, but it was easy for us to lose you/not follow up sanely. Having a person to contact, even if it’s purely reactive, counts as sales--especially because, as a developer who wants my company to buy $foo, it gives me someone’s name and contact info to give my boss. Once we added sales staff (both reactive and outreach), because we realized we were losing sales to your pre-sales team, our sales went up, but that happened relatively late in those first five years. So, I hear you, but I still think you’re undervaluing what Atlassian was doing there.
[…]
I did forget another thing though, which actually is another side of both that point and my original post: Atlassian segmented their products like nobody’s business. FogBugz was just FogBugz (and later optionally Kiln) so that you’d have just one single thing to decide on, but that corresponded to JIRA + Confluence + Greenhopper (theoretically, anyway), + Crucible + FishEye. Five separate times Atlassian could charge a customer, each of which could individually be cheaper than FogBugz.
Ted UnangstLet me start by saying that Wasabi as a strategic move was brilliant. If David disagrees there, I’m a bit surprised: FogBugz represented an awful lot of battle-tested low-bug code, and finding a way to preserve it, instead of rewriting it, made one hell of a lot of sense. I’m with you that the general thoughts in this forum that we’d have to be insane to write a compiler are misguided. Wasabi let us cleanly move from VScript and ASP 3 to .NET without doing a full rewrite, and I’d be proud to work at a place that would make the same decision in the same context with full hindsight today.
That said, I think Wasabi made two technical decisions that I disagreed with at the time and still disagree in with in retrospect. First, Wasabi was designed to be cross-platform, but targeted .NET prior to Microsoft open-sourcing everything and Mono actually being a sane server target. At the time, I thought Wasabi should’ve targeted the JVM, and I still think in retrospect that would’ve been a much better business decision. I really prefer .NET over Java in general, but I know that it caused us an unbelievable amount of pain back in the day on Unix systems, and I think we could’ve avoided most of that by targeting the JVM instead. Instead, a significant portion of “Wasabi” work was actually spent maintaining our own fork of Mono that was customized to run FogBugz.
There are two or three versions of Wasabi, depending on how you count. The first version was a simple ASP to PHP compiler, called Thistle. The input language was not customized. Then it became Wasabi, gained a few more features, and accepted an input language more like ASP++, but still output classic ASP and PHP. Then came Wasabi .NET with a whole new backend. That’s when I joined. Not a whole lot is written about this version except when Joel called it supersonic. Wasabi .NET is the craziest of the variants, bearing the least resemblance to any existing language, but still remarkably like ASP. The point of the exercise, after all, was to avoid changing FogBugz as much as possible.
[…]
Instead of thinking of technical debt as yesterday’s work that I failed to do, I think of it as tomorrow’s feature I can have today. You have to pay interest, but in the mean time you’re shipping a product, have a roof over your head, and are keeping the lights on. A much hipper programmer might say something like “you ain’t gonna need it.”
In one sense, Wasabi was a rather substantial payment on the debt we had accumulated. FogBugz was written in a now dead language. Building a compiler extended the life of the product, though of course now we had to pay for the compiler, too. So maybe it was more like a bridge loan, or refinancing.
For me the main way in which FogBugz has “lost” is that they silently discontinued the “FogBugz for your Server” version. The plugin system was great and we have our own installation on our own systems (no cloud allowed). With the “performance upgrade” they seem to have forked FogBugz, thrown out all the plugins, Lucene search and redid the GUI.
Scott talks to Jacob Krall from Fog Creek Software about how his team used the open source C# Roslyn compiler to bring their ancient VBScript-style language called “Wasabi” into the 21st century. They solved real-world problems in a systematic way with smart decisions and computer science.
Previously: Killing Off Wasabi.
5 Comments RSS · Twitter
We switched from FogBugz to Jira simply because it's a better match for Scrum. That's it.
I think Jira is a much worse product in pretty much every way, and so does everybody on my team. It's confusing and weird and extremely inconsistent (for example, different text fields where you can enter rich text use completely different rich text editors). But the simply fact remains that, if you want to do Scrum, you can easily do it with Jira, and not so easily with FogBugz. If you're doing Scrum, you're working with Jira, but against FogBugz.
Given that Scrum (or Scrum-like development methodologies) have become extremely popular in the past decade, I think this simple fact is sufficient to explain why Jira won against FogBugz. It probably has very little to do with Wasabi and pre-sales and all of that other stuff.
@Lukas Thanks for that perspective. I don’t use Scrum, so I assumed that FogBugz handled it because it sounds like it has those bullet-point features.
You can (in theory) do Scrum with FogBugz, but it really wasn't originally built for it. So yes, it "handles" it, the way a Ford Transit "handles" a race track. You'll get around the track eventually, you just won't be very fast, or feel like you're using the right car for the occasion :-)
If you want to use FogBugz with Scrum, you have to figure out how to do it, come to some kind of agreement with your development team, and then try to make them stick to that agreement.
Jira, on the other hand, is built for Scrum. It feels natural to use Scrum with Jira. For example, Jira uses the same terms Scrum uses, so if you know Scrum (or went to a Scrum training) you immediately understand how things fit together. It's very easy to do the kinds of things you do regularly in Scrum, like prioritizing the backlog, breaking a story into sub-tasks, working with epics, and so on, because all of these things actually exist in Jira, have the same names they have in Scrum, and already work the way they're supposed to work in Scrum.
