
Why Fogbugz lost to Jira - pdeva1
http://movingfulcrum.com/why-fogbugz-lost-to-jira/
======
solutionyogi
Having mainly done line of business applications my entire life, I have a
slightly different take.

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 provides Completion Date Probability Distribution chart and Burn Down
Chart [2]. Anyone who has worked for big companies knows that these two are
USELESS for them. They set a project delivery date and you just have to hit
it.

At my current company, we are going for SOC1 compliance. This forces an
amazingly complicated issue workflow and they implemented it very easily in
Jira. I am looking at FogBugz documentation on workflows [1], and I don't see
how we could have implemented the same in FogBugz.

I also feel that Jira has a better ecosystem for plugins and integrations then
FogBugz.

[1] [http://help.fogcreek.com/7483/statuses-categories-and-
workfl...](http://help.fogcreek.com/7483/statuses-categories-and-workflows)

[2] [http://www.fogcreek.com/fogbugz/features/project-
management/](http://www.fogcreek.com/fogbugz/features/project-management/)

~~~
Meekro
_They set a project delivery date and you just have to hit it._

Do you find that this really works out, in practice? Joel has argued[1] that
the only schedule worth anything is the one set by the developers themselves.
Management can set relative priorities (X is twice as important as Y), but
trying to force a faster deadline on the developers is like trying to make
your Linux box run faster by renice-ing every process to -20.

Now, the problem with developer-set schedules is that they tend to
underestimate how long things will take. Hence, FogBugz figures out how much
each developer underestimates on average, and builds bell curves for the
realistic completion time.

[1]
[http://www.joelonsoftware.com/items/2007/10/26.html](http://www.joelonsoftware.com/items/2007/10/26.html)

~~~
codeulike
_Do you find that this really works out, in practice?_

No. Good luck persuading the management to try something else!

~~~
iwwr
There may be a niche for enlightened managers or startup funders to promote
such a thinking. If successful it will lead to a clear competitive advantage.

~~~
retrogradeorbit
This is true. But there is no competitive advantage in going and broadcasting
to all your competitors exactly how you achieved the advantage. So the
development shops that succeed using this will keep it tight.

------
JimDabell
There's an interesting discussion happening on Reddit involving ex-employees
of both companies:

[https://www.reddit.com/r/programming/comments/3n2sc1/why_fog...](https://www.reddit.com/r/programming/comments/3n2sc1/why_fogbugz_lost_to_jira/)

~~~
outworlder
An interesting point from that, since everyone likes to bash Wasabi:

> "If we hadn't done Wasabi, then we'd have had to rewrite all of FogBugz, and
> that would've killed the company. Wasabi also gave us stuff that developers
> are only now rediscovering, like code that executes on both client and
> server (e.g. via server-side/client-side React), that even gave us a
> development edge. I've written about this at length
> ([https://news.ycombinator.com/item?id=9779133](https://news.ycombinator.com/item?id=9779133))
> and won't revisit it, but while I think that Wasabi targeting .NET may have
> been a mistake, Wasabi itself was not a mistake."

~~~
derefr
What I always fail to understand about Wasabi: why did they keep the code in
the source language and compile to CLR object code, instead of running the
_same_ parser with a different codegen target, to transform the PHP wholesale
into valid C# _once_ , and then overwrite the codebase with that?

~~~
nchelluri
Do you really want to inherit autogenerated code? I doubt the autogenerated C#
would be nearly as easy to understand or read as the original Wasabi code. I
also think writing CLR object code, if it's anything like writing assembly,
would be much easier to generate than C#.

~~~
derefr
Well, it _is_ what they eventually did, after ten years. With tons of tweaks
to make it spit out natural-looking outputs. I just don't understand why they
didn't go that way from the start.

~~~
nchelluri
I was unaware of that. I'm still betting they didn't go that way initially
because of the inherent difficulties of autogenerating C# code.

------
MichaelGG
Yet FogBugz still feels way easier to use. Every time I'm in an Atlassian
product, mainly Stash and JIRA, the UI sucks. I use them several times a week
and still get lost. Maybe I'm dumb, but I don't seem to have this problem on
other systems. But hey, at least JIRA isn't the craptastic laggy pos that is
Podio.

Certainly right that I've never seen FogBugz outside of myself or customers.
Also, I think the name must hurt them. It feels dumb bringing up "FogBugz yeah
with a z". As silly as a reason that is, I think it carries some weight.

Content marketing may have helped them with SEO, no? Not that it SEO alone
would close large enterprise deals.

Oh and the plugins on FogBugz did suck. I remember setting up a hosted
account, and wanted to plugin to Github. Support sorta mentioned being able to
custom hack something up, but IIRC, didn't actually give us any simple way to
achieve it. (This was several years ago so perhaps I'm mis-remembering.)

~~~
rabid_fish
I've used both, and I can only imagine your complaints about JIRA's UI are due
to how it's been configured for your use.

The out of the box user experience is the best I've seen for a web
application. A robust yet easy to use 'search' feature is at the heart of many
things, like the scrum and kanban boards, as well as widgets that can be put
on your own personalize dashboard. You get a nice visual designer for setting
up workflows, and you can easily create new fields for issue types and have
workflow depend on those fields.

I also find Stash to be well thought out and easy to use if your use-case is a
pull-request workflow tied to JIRA. Sometimes it's not intuitive how to
navigate around if you're just trying to view source, but that's not the
selling point. If you're trying to navigate source history, use your local
source control client, that's what it's built for.

~~~
Domenic_S
Whoever designed JIRA's psuedo-markdown text format deserves a special place
in hell.

~~~
skrebbel
The relevant XKCD: [https://xkcd.com/277/](https://xkcd.com/277/)

~~~
sbierwagen
Was that really the xkcd you wanted?

~~~
Steltek
I actually misread the URL as [https://xkcd.com/927/](https://xkcd.com/927/)
(having memorized that number like everyone else here, I'm sure) until I saw
your comment. #277 is definitely not right.

~~~
doodpants
#277 sure seems to me like a reasonable reply to "Whoever designed <such and
such> deserves a special place in hell", which is what it was posted in
response to.

------
command_tab
And yet, "Creating a JIRA task is like going to the fucking DMV."

[https://twitter.com/jesseherlitz/status/648557144845910016](https://twitter.com/jesseherlitz/status/648557144845910016)

~~~
shill
Does the opposite kind of user exist? Has anyone ever met a fanatical JIRA
lover?

In my experience there are only people that tolerate JIRA on one side of the
spectrum and a bunch of people that hate JIRA on the other side.

~~~
morgante
I love JIRA and would absolutely advocate for using it over any other tracker.

With just a little tweaking (30 minutes or so on a fresh install), I can have
it perfectly configured to match my ideal workflow.

~~~
jackhack
Can you please elaborate on this configuration? What is the general nature of
the configuration changes you're making? Or, how is your workflow affecting
the product. I ask as I am in an organization right on the cusp of
implementing JIRA, and I would love to steer the implementation team toward a
more useful configuration than the clunky defaults, with which I've had prior
experience.

~~~
morgante
The biggest things for me are:

* Setting up several statuses (more than in the default) to reflect backlog, selected, in progress, testing, deployed

* Creating an appropriate board which splits everything into columns by status and rows by user

* Setting up a few quick filters to find things like anything which has been in the backlog for more than 6 weeks or bugs which haven't seen activity in the last 48 hours

* Integrating GitHub. Being able to kick a ticket over to QA from your commit message is awesome.

Beyond that, I mostly focus on stripping out default things to make the
workflow simpler. I don't need my software to enforce that I can't move a
ticket to deployed straight from in progress, and stripping out those extra
rules makes it easier to deal with.

~~~
jackhack
Much appreciated. That's a great opener for a discussion with our impl. team.

------
dannyrosen
I brought Fogbugz into two organizations (100+ accounts) as a QA Engineer and
it worked great -- when it came to bugs.

When we started doing agile (and then "Agile" ... ugh) development the entire
process broke down. There were no (good) plugins that could do kanban and
moving features from state to state to state dramatically increased the size
of an items log. That, along with the friendly, and then suddenly not so
friendly filtering lead to our team dropping the product and moving to Jira.

While Fogcreek's "Fastbugz" was a gallant effort in modernizing the
application stack and speeding up page loading time, it fell short as it
didn't functionality support feature _and_ bug management.

I should note, we had reached out to Fogcreek with all of our requests and
critiques but they weren't interested in hearing us out passed the usual
account or customer service manager.

------
spolsky
Sorry, Prashant, you lost track of the plot of the story somewhere along the
way.

(creator of FogBugz, here)

FogBugz won and Jira won, but they were playing different games.

I wanted to make software development better for programmers. When I started
creating Fog Creek Software in 2000 programmers were treated like typists.
They were not paid very well (my starting salary was $33,000). There was
almost no thought around how software should be developed. Companies that
scored high on the Joel Test[1] were almost unheard of.

The LAST thing I wanted to do was make another tool of oppression for
management to impose gantt charts and deadlines and strict rules about who has
to sign off on things.

I set out to make software development better for programmers by blogging[2]
and by building a company that would be a great place to work[3].

In 2000 the only way to do that was to bootstrap it. With a team of four
people we couldn't build anything complicated. We started with bug tracking
software because at least we could touch one aspect of programmers' lives with
our philosophy.

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. Anyway Atlassian is going public with this enterprise software, good for
them, I'm sure they're going to enjoy their well-earned private jets.

But FogBugz was the means, not the ends, and at Fog Creek our ambition was not
to be the world's greatest bug tracker software company, it was to fix things
for developers. So we kept plugging away at other ideas. Some of them were
kinda dumb. Some were moderate successes.

Two of them, Stack Overflow and Trello, were huge hits and spun off into
separate companies. Stack Overflow, thanks to Jeff Atwood's inspired
leadership, has had more impact on making software development better for
programmers than any bug tracker ever will. Trello has grown as popular in
three years as Jira grew in 15 years.[4]

Neither of them would have been possible if we didn't have the cash cow of
steady FogBugz profits. That's what bootstrapping is, folks! You build one
thing and use it to build a bigger thing.

In the meantime I think the world has figured out that programmers are writing
the script for the future that everybody is going to live in, so conditions
have gotten better. In big cities employers are falling over themselves to
invent new ways to pamper and delight their programmer employees, with the
massages and the sushis and the dog yoga. We programmers built ourselves
hundreds of amazing tools, from github to npm to ci tools, build tools, IDEs,
code refactorers, etc. etc. that make programming a million times better than
it was in 2000, and bug tracking is just a slice of that pie and not a
particularly important or interesting one.

But that said, FogBugz is still very popular and very profitable and thousands
of teams use it every day, and we're still reinvesting those profits in making
it better and in developing new products to make the world better for
developers, and even though it doesn't support pointy-haired micro-managers
and doesn't allow you to create a custom workflow requiring that a VP-or-
higher sign off on bug reports, there are still small, collegial teams of
smart developers who have figured out that this is how they want to work.

[1]
[http://www.joelonsoftware.com/articles/fog0000000043.html](http://www.joelonsoftware.com/articles/fog0000000043.html)

[2] [http://joelonsoftware.com/](http://joelonsoftware.com/)

[3] [http://www.fogcreek.com/](http://www.fogcreek.com/)

[4] [https://goo.gl/hTXXPG](https://goo.gl/hTXXPG)

~~~
Vendan
wow, $33,000 15 years ago? That really puts a spin on me making $36,000 6
months ago, working in 4 languages and 2 platforms to build a really
complicated SPA web app and mac flash content player system. Glad I got out of
that job!

~~~
baus
From my own personal experience, things weren't bad in the late 90s up to the
point of the .com crash. Starting salaries in valley were $45k-$55k. There was
a lot of competition for strong candidates, and working conditions were pretty
decent. I do commend Spolsky for providing good working conditions in a market
like NYC where the current trend seems to be to jam as many people in a space
as possible.

------
baus
It could be argued that Trello will eventually be larger than either of these
products, so I don't think the story has been completely told. I've used Jira
as a manager in both a large and a small installation and hated it both times.
It feels like 90s bug tracking system with huge forms and intractable
workflows.

With that said, Spolsky (although I think a lot of his writing is fantastic)
rarely addresses his mistakes.

~~~
__david__
Trello doesn't really seem like a bug tracker. I haven't used it though—maybe
I'm just missing something?

~~~
joncooper
Agreed. I kind of don't get Trello. Always thought of it as kind of a
lightweight "stack of cards" analogue best used for simple high-level planning
along the lines of a Kanban board. Is that how people use it?

~~~
perrylaj
We used it recently as a kanbanish/scrumish board for a recent development
cycle and it worked out pretty well. We had separate boards for each sprint,
and a backlog board that contained some broad-swipe categories. It would
definitely be nice if it had better integrations with fogbugz (which our team
also uses) or other bug tracking platforms, but I imagine it would be
challenging to do that and maintain its extreme ease of use/simplicity.

------
afsina
Also Atlassian products are multi platform. Whereas fogbugz is windows only
for the server side. That is a deal breaker for many.Additionally unlike
Fogbugz Atlassian products are DB agnostic.

~~~
julianz
Huh? We've been running Fogbugz on a Debian server with a MySQL database for
years and years. Fog Creek may encourage Windows now but it still runs on
Linux just fine.

~~~
afsina
They are no longer selling Linux versions. Also only MySQL and mssql are
supported. MySQL is not recommended. [http://help.fogcreek.com/7389/fogbugz-
system-requirements](http://help.fogcreek.com/7389/fogbugz-system-
requirements)

------
alexwebb2
Slightly off topic here but since everyone's chiming in about their
experiences with bug trackers, I figure somebody might find it useful.

I did a pretty intensive search involving trials of a couple dozen trackers
about two years ago when we decided to ditch Jira due to some serious
performance and UI issues. I tested pretty much every serious contender on the
market.

I ended up going with YouTrack and it's been pretty fantastic. One of those
by-developers, for-developers things with a lot of functionality out of the
box and a decent API for more advanced stuff, and most importantly it has very
good performance and a sane UI. It does what it's supposed to do and then gets
out of the way, which is exactly what I wanted. I recommend taking it for a
spin if you're looking for something along those lines.

------
atesti
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. And stopped updates for the
server version:

[http://help.fogcreek.com/fogbugz-release-
notes](http://help.fogcreek.com/fogbugz-release-notes)

And now just recently there was a little bit of activity, like that they now
offer a VM of some kind with the new version. But I think we can't use that
because it is the expensive, unlimited user license and they must install it
somehow and plugins would still be gone, which we depend on.

And for all of this there is little to no communication.

The stop of "Kiln for your Server" was also done extremely quitely.

~~~
atesti
Here is the FAQ which outlines that plugins and the old FogBugz for your
server has been discontinued:

[http://help.fogcreek.com/10706/future-of-for-your-server-
faq](http://help.fogcreek.com/10706/future-of-for-your-server-faq)

Very sad

------
mariusmg
Seems to me Atlassian "won" because they had a actual sales team not because
of "technology".

~~~
omouse
They won because they allow managers to be in control and authoritarians. I've
seen more than 2 managers who take over JIRA and lock down permissions and
create custom workflows and _all_ of them insist on having swim lanes and 5+
columns. So to move one little ticket across the board took 4+ drags. If you
have a heavy-weight process where people are actually signing off on things,
then yes it makes sense. But otherwise it just irritates everyone.

They won because they appealed to the true buyer in the office; the CTO or VP
of engineering, but they really appeal to the control-freak and micro-manager.

When I used Fogbugz in one office, it was the devs that pushed for its use and
the project managers and other execs weren't able to screw it up; there was no
obvious way of creating custom workflows or locking things down too much.
Fogbugz let us get work done. JIRA in the hands of a micromanager makes me
want to chew glass.

~~~
vailripper
We were on Fogbugz for many years, but eventually left to Jira because the
Agile workflow is absolutely horrid.

Micromanagers can screw anything up - you can invent some pretty insane
workflows using the FogBugz workflow tool, if you want to :)

------
osullivj
I was working at a large British bank in 2005 when Jira started to get
adoption by several teams. The approved bug tracking product was ClearCase
ClearQuest. If you think the Jira GUI is ropey you should see ClearQuest.
Absolute nightmare. By contrast Jira was free to get started, and much nicer
than corporate approved incumbents. They called it land and expand!

------
lloydde
This takes me back ten years to 2005. I was the QA lead at an open source
company and we really wanted to use FogBugz. An operations engineer imported
all of our bugzilla issues and we were starting to put FogBugz through its
paces, but what we couldn't figure out was FogBugz licensing for all of our
OSS community. In the en, I think Joel did get back to us and tell us their
product was not a fit.

Another adviser replied to the thread below (oldest at the bottom) that Apache
also uses Jira.

In the end we kept using Bugzilla.

    
    
      From: bizguy
      Subject: RE: [Staff] FW: Joel Spolsky intro?
    

I second FogBugz being unreachable. Also, Jira has a MUCH more impressive
client list:

Cisco, Oracle, HP, NASA, JPL, CERN, MIT, CalTech, Cornell, HBO

    
    
      From: ceo
      Subject: RE: [Staff] FW: Joel Spolsky intro?
       

in view of the FogCreek people being unresponsive, and advisor's instant
"don't use them" response, I'd like for us to do a bit more due diligence on
Jira. I notice that they have per-server licensing ($4800), with unlimited
users.

    
    
      From: me
      Subject: Re: [Staff] FW: Joel Spolsky intro?
    

jira is java based and requires running tomcat which can be a bit of a pig.

It is supportive of open source communities. That is about all I know about it
right now... I will look at it more tonight.

    
    
      From: advisor
      To: ceo
      Subject: Re: Joel Spolsky intro?
    
      Avoid, use Jira... 
      
      ceo wrote:
      >
      > Dear friends,
      >
      > I'm trying to get a hold of Joel Spolsky so we can work out some 
      > arrangement for using their FogBugz bugtracking system.  Please let me
      > know if you know Joel and can help with an intro, since my blind email
      > isn't getting a response.

------
yaur
A big thing with the pricing... If I'm an individual contributor and want a
bug tracker, I can drop 10 bucks on a JIRA license (out of pocket) or convince
someone from management that I need it and that they need to pay for it.

------
davidw
Did Fogbugz really 'lose'? It's not as if bug tracking systems are a winner-
take all market with strong network externalities. Granted, it did not 'win as
much' as JIRA, but that's not necessarily a loss. One of the cool things about
many businesses is that they are positive sum games. Maybe FogBugz works
better in some niches and still generates a nice living for the people who
work on it.

------
protomyth
Wasbi had nothing to do with it. JIRA caters to micro-managing mangers and
FogBugz didn't. That is the simple lesson in enterprise. Trying to give a
technical explanation isn't really telling the story.

------
mrweasel
Jira certainly is more popular, but I never viewed the two products as being
in direct competition. I don't know about the inner working and finances of
Fogcreek, but given that Fogbugz is still around they've may have lost
anything.

Pricing would certainly be a knob Fogcreek could tweak, if they believed that
they where losing to Jira in some shape or form. Given that they haven't
lowered prices or expanded their free tier sales of Fogbugz could be on the
precise path that Fogcreek want for the product. Maybe their selling extremely
well in a marked that most HN readers just aren't in contact with. A marked
that doesn't mind the added cost.

It's different approaches to sales, make a little money from a large pool of
customers, or sell a more expensive product/service to a smaller market. Both
strategies are completely valid, but due to Facebook, Twitter, Instagram, Uber
and whatnot many will falsely assume that more customer is always better.

------
pbreit
This is a terribly uninformed perspective on the monumental achievement of
large success. If anything, fog bugz "lost" to stack exchange which, imo, is a
more profound achievement than the over crowded project management category
that still hasn't put out a product that has broad appeal.

------
maxharris
I had to use Jira at my last job. I could never figure out what it did that
you couldn't do in github with less trouble and fuss.

I can't say that I would absolutely refuse to work at a place that uses Jira,
but it is definitely something that would make me lean towards another offer.

------
martingordon
My Jira experience was absolutely terrible. We were an 8 person team at time
and looking for something more robust than Trello and ended up settling on
Pivotal Tracker.

I signed us up for an Atlassian Cloud trial and right away things weren't
looking good. I was expecting to dive right in but instead had to wait 30
minutes until my instance was ready or whatever.

They only offer a 7-day trial. How am I supposed to properly evaluate
something as fundamental as an issue tracker in 7 days? That's not long enough
to learn to use it and then get the team to try it out for a small project.

Worst of all were the 5-10 second load times on each page. I contacted support
to see what they could do but they weren't too helpful and I stopped using it
2 hours into the 7 day trial.

~~~
xrstf
In my experience, most Atlassian products are slow as hell, with Bitbucket
being among the faster ones. Confluence can maybe control a space shuttle with
all its features, but it's slow to a point where it becomes unusable.

We evaluated JIRA as well, but it didn't work well for people like who are in
many different projects at once and don't want to spend days trying to build a
view for all those issues (that encompasses swim lanes and such). Also, as
you've mentioned, it's pretty slow.

We settled with Trello and are relatively happy.

------
chaitanya
The one feature of Fogbugz that I really like (and the reason I use it) is
evidence based scheduling:
[http://www.joelonsoftware.com/items/2007/10/26.html](http://www.joelonsoftware.com/items/2007/10/26.html)

It takes away a lot of pain associated with giving estimates, especially from
a manager's point of view. Devs need to break their tasks down to subtasks of
sufficient granularity, and estimate the number of hours/days it would take
them to complete each of these subtasks. Fogbugz does everything else, and
gives a nice probability distribution chart of completion date that you can
share with the stakeholders.

------
lmm
I don't think it was Wasabi so much as Windows. You didn't have to use Wasabi
to write plugins for FogBugz, but you did have to use .net. The kind of people
who read Joel's blog run on *nix, and probably have some Java in their stack;
if you give them a .war that runs on Tomcat then they know what to do, and if
they don't know then there are plenty of open-source tutorials. If you're
giving them a .net product to deploy on a windows machine, not so much.

I think the final chapter is yet to be written though. Trello is a joy to use,
much better than Jira. And AIUI it's on a much more developer-friendly stack.

~~~
toyg
_> "The kind of people who read Joel's blog run on _nix, and probably have
some Java in their stack"*

I'm afraid you're really off-base there. Spolsky is a MS alumni and his core
followers have always been people living in the MS ecosystem. The forums he
kept for a while were overwhelmingly populated by people talking of VB and
then .NET. StackOverflow was clearly dominated by .Net questions for the first
few years.

His choice of platform, when it came to developing his own software, was never
really in doubt. Note that FogBugz was not even the actual product he started
the company for; that was a proto-blogging publishing platform called
CityDesk, which was Windows-only and meant for the general public. FogBugz was
an internal tool that he pivoted on, thanks in great part to the cred he had
built by blogging candidly on software development matters (at a time when
this was very rare).

If you now see his customers as "running on *nix", it's because the world has
changed. Now the bugtracker is looked after by devops, people who started
working after the wave of cheap Linux server that built the modern web had
long settled.

~~~
lloydde
> I'm afraid you're really off-base there. Spolsky is a MS alumni and his core
> followers have always been people living in the MS ecosystem.

What do you mean by core followers? You underestimate his influence.

I haven't worked in the MS ecosystem in my 15 year career across six
companies. I've regularly seen his book around and his writing is referenced
from time to time. I'd go so far to say some of those environments I've worked
in and some of the people championing his work have been somewhat anti-
microsoft.

------
meshko
Never used Fogz, but Atlassian products are so astonishingly bad that it is
hard to find anything about them inspiring.

~~~
meshko
I think the fact that my useless inflammatory comment didn't get immediately
downvoted to hell is proof that I'm right!

~~~
emmelaich
"bad" by itself doesn't mean much; the important thing is the relative
goodness.

What were open source projects going to us instead? RequestTracker? Scarab?
Bugzilla?

All of those were much worse than JIRA for development.

RT is fine for helpdesks but ugly as hell and no integration with SCMs.

Scarab never got to a satisfactory level of maturity.

Bugzilla? Just say no.

I've been a JIRA admin for 5 years now, and we seriously considered Fogbugz as
well. I've never regretted our decision even though we've had plenty of
issues( _) with JIRA.

_ free pun included.

------
mixmastamyk
On the other hand, I wish bitbucket were more popular compared to github. It
doesn't seem like they invest much into bitbucket, as some silly issues have
persisted for years. Have they given up?

~~~
rajksarkar
Nor true - we have been investing quite a lot on Bitbucket. Check out our most
recent blog post:
[http://blog.bitbucket.org/2015/09/22/1-in-3-fortune-500-comp...](http://blog.bitbucket.org/2015/09/22/1-in-3-fortune-500-companies-
agree-bitbucket-is-the-git-solution-for-professional-teams/)

~~~
jordigh
You're letting Mercurial die, though.

And for all that investing, you are not fixing the bugs that annoy people the
most. You let them languish for _years_ :

[https://bitbucket.org/site/master/issues/11813/allow-
annotat...](https://bitbucket.org/site/master/issues/11813/allow-annotate-
blame-with-whitespace)

[https://bitbucket.org/site/master/issues/5008](https://bitbucket.org/site/master/issues/5008)

[https://bitbucket.org/site/master/issues/11864/ignore-
whites...](https://bitbucket.org/site/master/issues/11864/ignore-whitespace-
toggle-in-the-ui-bb)

------
zkhalique
I have a question about raising VC money earlier. If you want to grow fast and
push some free platform out to change the world, what is main danger in
raising VC? I'm talking about the VCs these days who invest in companies that
make open source like NGiNX, MySQL etc. And you need resources to grow, if you
want to beat competitor platforms.

I mean logically, if they've already given you the money and there isn't any
way they can take over governance of the company, then the only leverage I can
think of is signaling in future rounds. And if you weren't even going to raise
one VC round, then at that point you may as well raise exactly one and then
signaling is irrelevant. Yes you've diluted yourself 20% and now you've got a
board member that wants you to grow fast, but so do you. Of course, I'm
assuming here that you failed to raise on Kickstarter, and you aren't making
enough $ to hire people to do
development/testing/security/evangelism/PR/marketing/operations/etc. anytime
soon. Why waste years of your life when you can hand the project off
eventually to a community you've built, and move on? If you want to retain
control over the project forever, can always be BDFL of the community, at
least until some better-funded company forks it. I just really want to
understand, what is the reason that guys like DHH say VC can control you after
you take their money?

~~~
wpietri
Once you take money from investors, you have both a legal and a moral
responsibility to them.

It's important to remember that selling equity is really selling something,
just like selling a product. You can't sell something, take somebody's money,
and then just not deliver. What you are selling to investors, generally, is
return on investment.

The real problem comes in because founders and VCs have different
understandings of "grow fast". There will come choices that have different
levels of risk. VCs always want you to take the high-risk, high-reward path,
because they have a portfolio company and are looking for the few really big
winners. You, on the other hand, are trying to build something (team,
community, product, etc), and so you will favor slower but safer growth.

I guess in theory you could sell VCs on a high-growth approach and then turn
around and say, "Ha ha, fuck you, we're going to keep your money and try to
grow modestly." But a) VCs are way better at their game than you are, so
they're hard to fool, and b) then you're an asshole, which is bad on its own
and also has consequences for future relationships (and future funding). Plus,
if you're in a VC-fundable space, you'll probably have competitors who are
also taking money, and they'll be able to outspend you on future rounds.

~~~
EGreg
No, assuming you're not an asshole, just want to reduce risk or make your own
decisions in good faith, how can they force you to make a decision you
normally wouldn't make?

~~~
wpietri
To get the money from VCs, one has to sell them on the notion that the company
will to scale until it can swallow the moon. Suppose I take their money and
say, "Sorry, now I want to reduce risk! Too bad, suckers!" I'd say that makes
me an asshole.

If you've taken a small amount of their money, then maybe they can't legally
force you to take more risk than you think is wise. (They can, however, make
sure you're unlikely to get money from anybody else, either now or in the
future.) But if you've taken a B round or more, then a founder probably
doesn't have control.

------
jeffmk
Has anyone had experience with Redmine [1]? It's quite easy to use and extend
via its plugin system, but I don't see many people who have encountered it in
the wild.

I think its horrendous out-of-the-box look-and-feel detract heavily from its
appeal. Nowadays I'd probably lean toward Gitlab, which seems to offer much of
the same but appears much more modern.

[1] [https://www.redmine.org/](https://www.redmine.org/)

~~~
simoncion
I've used Redmine. It's a _MUCH_ better Trac.

Out of the box, it's ugly, but -frankly- who cares? We're all programmers
here, and value proper function much more highly than lacquered handles. :)

~~~
porker
> Out of the box, it's ugly, but -frankly- who cares? We're all programmers
> here

Uhh, humans? ;)

I find a better-looking tool to be more pleasant to work with, and Redmine was
not-as-painful-but-almost as JIRA for me, for the experience being so poor.

------
mostlystatic
My guess is that Fogbugz is a cash cow without much new development effort.
The focus of FogCreek's founders is on StackExchange and Trello now.

------
tbrock

      This meant they couldn't use all of the ecosystem and amazing tooling around Java
    

I've never laughed so hard in my entire life.

------
dragonsh
I am still not sure if fogbugz lost. In general simple systems are always hard
to built.

In general while doing a project with fixed date approach Jira issue tracker
is indeed not inline with the source code. So there is a discrepancy between
what is in issue tracker and whats in the source tree. Moreover developers
cutting corners to meet the fixed date is a technical debt for future and Jira
promotes it.

Fogbugz with its probabilistic approach is better matched with the actual
source code, since even though developers over or under estimate, its
probabilistic distribution analysis puts standard deviation and means put in
front of their eyes to do better. So in general fogbugz approach results in
better source tree and less technical debt.

------
fideloper
Who is Prashant Deva and should I care about their opinion?

Did Fogbugz actually lose? Do they even have the same market (enterprise vs
smaller)? Perhaps they just fine operating at a smaller volume.

Isn't the product being "too basic" a sign of focus? Perhaps the author
needs/wants more features, but that can't be generalized for all of Fogbugz's
audience.

I've heard just as many owners say "I don't want as many features as
competitor X".

That all being said, there are some good things in there - perhaps Fogbugz
could look into a partner ecosystem. Making your own language is probably a
bad long-run choice.

However I get the feeling this is comparing apples to oranges.

------
rsobers
Won based on what criteria?

Atlassian has over 1,100 employees. When I was at Fog Creek we had ~30.

So if we're talking about profit per employee, I can assure you the people who
built FogBugz don't feel like they've lost anything.

------
mijustin
What metric are we using to determine who "won" here?

Did Jira "win" just because OP likes it better?

Because both companies are private, we don't really know how much _profit_
either product has made.

~~~
chris_hawk
In reality, it's a double-win relative to the goals each company was striving
for - and acheived!

In the author's mind, Jira wins because it's OMG ENTERPRISE and going public.

------
djur
Couldn't disagree more on the integrated wiki point. Issue trackers with
integrated documentation pages (wikis or otherwise) make it really
straightforward to generate docs as a byproduct of working on tickets, or to
resolve support requests by linking to the docs. Eventually you will want an
external documentation tool, but Atlassian doesn't have one that's any good
(Confluence is by far the worst wiki-like application I have ever used).

~~~
vailripper
Really? Have you tried using the Fogbugz wiki? I will take Confluence any day
over that slow bloated POS.

------
robotnoises
>> While most of these plugins didn't offer much in terms of functionality,
for the person making a decision, it definitely helped to tip the scales in
Jira's favor.

For me, this kinda encapsulates the problem with Jira. Jira is extremely
impressive in the number of features, plugins, and customization opportunities
it offers, and yet, I can't honestly say even half of the stuff is in any way
helpful to me as a developer.

~~~
zem
as always, a _different_ half is helpful to any particular user. add all the
users together and you're back with the full feature set.

------
PretzelFisch
I would like he to define lost. Fogbugz is still around and profitable.

I have always seen Fogbugz as a support tool first, bug tracking kindof it's
what they built for Fogcreek's process(for Copilot support and development).
If you did everything like them it probably was a great fit. Jira on the other
hand I have always seen as bug tracker.

------
skrebbel
A bit off topic, and I know I'm sounding like a condescending jerk here but I
mean it: but why do people love bugs so much that they want to purchase an
entire database program to track them? I mean, if you have more than 10 bugs
that are highly important to keep track of, it seems to me that you have much
larger problem than whether to purchase JIRA or FogBugz.

I mean, either a bug is important to you so prioritize fixing it, or it isn't
important to you so you can just ignore it and see if it surfaces again.

 _Every single team_ I've seen that used a bug tracker ended up with hundreds
of issues, status of 90% of which was unknown, maybe already fixed, maybe not
relevant anymore because the entire component got overhauled the other day by
Joe. What's the use of this stuff?

I got this from a blog post (by Ron Jeffries I believe, but I forgot), but
basically his idea was that the moment you turn something that _you don 't
want to have_ into a formalized process, people tend to bias towards getting
more of it. If you are forced to choose between fixing a bug or forgetting
about it, you're urged to fix it fast. If you can just "file the bug and go on
with your work", the bug stays.

~~~
peterdkovacs
You've got more than 10 bugs. You just don't know it yet.

But really, "bug tracker" is just a colloquial expression for the more
accurate "issue tracker" which can definitely include things like
improvements, new features, A/B tests you want to run, etc.

~~~
nobleach
It is possible that their software isn't large enough to have 10 bugs... they
could be implementing FizzBuzz.

~~~
itsybitsycoder
Where can one get a job as a professional FizzBuzz developer?

I think if a program is big enough to devote a software developer to it full-
time, it's going to have at least 10 bugs. Maybe they are small or unimportant
or so obscure that none of the users actually run into it, but they're in
there somewhere.

------
otabdeveloper
Programmers hate being held accountable, yes. (This is logical given that they
control so few of the risks.)

But in the end, accountability is the reason why you're being paid that
salary, not knowledge of framework APIs or algorithms.

Embrace that responsibility and process, don't fight it.

------
dwd
Surprised no mention of Kiln which was a really nice product when I first used
it back in 2008. The ability to inline comments in a code review that then
hooked back to the job in FB was fantastic.

GitStash is getting there now, but the Jira integration is still a little
lacking.

------
mangeletti
What about the name? He could have potentially left out the most important
mistake Spolsky ever made, which is to name a product Fog Buzz. He might as
well have named it Rain Smelt, or Lamp Shade. It sounds terrific once you use
and like the product, but it doesn't sound remnisent of any kind of successful
brand ever. Even the use of 2 words is a departure from the norm. Most of the
big brands have 1-word names, and this is not s coincidence. Even Facebook was
changed from The Facebook. Brand matters, and names matter.

To play devil's advocate with my own argument, 37 Signals is a bit different
as well and people (perhaps more so in the tech community) loved the brand,
but the thing is, they used "Basecamp" as their product name.

~~~
julianz
Possibly your most important mistake is not reading the name correctly. It's
Fogbugz. One word.

~~~
mangeletti
Potatoemuffintrain. See what I did there. 3 words do not become 1 word, simply
because the proper spaces are omitted.

I will say though, for many years I have thought the company was called Fog
Buzz, (not Bugz).

------
ohitsdom
> Fogcreek invented their own language. This meant they couldn't use all of
> the ecosystem and amazing tooling around Java

Java? I believe that should be .NET.

~~~
afsina
Op means unlike Atlassian, which is mostly a java shop.

------
eikenberry
> This meant they couldn't use all of the ecosystem and amazing tooling around
> Java [...]

Does anyone else get the same confused feeling whenever they read things like
this? Every experience I've had with the Java/JVM ecosystem has been anything
but amazing to the point where I now avoid it like the plague. I can't believe
I'm that much different than everyone else, but I see this often enough that
it makes me wonder.

~~~
mindcrime
_Every experience I 've had with the Java/JVM ecosystem has been anything but
amazing to the point where I now avoid it like the plague._

Nope, just the opposite here. The JVM ecosystem is hands-down my preferred
environment for building / deploying pretty much anything.

"Different strokes for different folks" and all that...

------
Grazester
I not heard good things about Jira's ease of use

------
lifeisstillgood
1\. Make a JIRA plug-in that turns JIRA into Fogbugz

2\. Profit

------
curiousjorge
I think the last bit about what _didn 't matter_ has a huge take away home
value. It's ironic that so much crap we read today drives home these two
things that we focus so much on:

1\. Content Marketing

2\. Sales Team

~~~
grossvogel
Joel on Software has 6 posts over the last 3 years. I'm not sure how long Jira
has been winning (whatever that means), but it doesn't seem fair to say that
Content Marketing doesn't work when the blog in question isn't actively
updated.

~~~
benologist
They're actively marketing their blog on HN -

[https://news.ycombinator.com/from?site=fogcreek.com](https://news.ycombinator.com/from?site=fogcreek.com)

~~~
grossvogel
You're right, I hadn't even considered the Fog Creek blog, but the article
specifically talks about Joel on Software.

And Atlassian's blog seems to be in the same ballpark as Fog Creek's:
[https://news.ycombinator.com/from?site=atlassian.com](https://news.ycombinator.com/from?site=atlassian.com)

------
draw_down
I still can't believe they invented their own language... but #1 seems like it
would have been enough.

I hate using JIRA, though, just like I hate using all Atlasssian products, so
it would have been nice if FogBugz won.

~~~
protomyth
Ericsson and Sun invented their own languages. If your a tool company,
treating language as off-limits seems limiting.

~~~
draw_down
You have a point, I guess I'm more flabbergasted by the particular language
they chose to invent. Also, Fog Creek ain't exactly Ericsson or Sun.

~~~
protomyth
Fog Creek probably had more resource than Yukihiro Matsumoto, Larry Wall, and
Guido van Rossum did.

~~~
vacri
Ruby, Perl, and Python weren't meant to be in-house languages created to
support a commercial product. Not to mention that in their infancies as hobby
projects, they didn't have to hit sales deadlines.

