
GitHub is eating Jira - pdeva1
http://movingfulcrum.com/github-is-eating-jira/
======
pech0rin
This seems to be a somewhat baseless claim while using 3 open source projects
as examples. Jira makes money off commercial licenses, and is a much more
feature rich and productive tool for a large organization.

If you can show me atlassian profit loss (hint there isn't any:
[https://investors.atlassian.com/financials-and-
filings/finan...](https://investors.atlassian.com/financials-and-
filings/financial-statements/default.aspx)) then I would believe this.

~~~
pureprotein
I know for a fact that a lot of fortune 100 companies are switching their code
hosting from Atlassian Stash to Github, at the price of losing tight
integration between issues and code, not to mention all the headaches involved
in switching. I think it's a matter of time before Github comes out with a
better issue tracking system and everyone jumps ship.

~~~
tropo
Wait, what???? People buy this stuff just to host code????

You don't need either of these for code hosting. Use git as intended by Linus.

If you really feel the urge to complicate things with a web browser, note that
cgit is the high-performing repo viewer. Stay far away from Atlassian's
bloated Java.

------
PaulHoule
Github issues is good because it does not have so many features.

If they started adding features to Github issues pretty soon it would be as
slow and hard to use as JIRA. It's been a big problem with issue tracking
systems for a long time. Once you add enough features and form fields, then
the "add ticket" page looks like the cockpit of an old Boeing 747 (not the new
glass cockpit.) Then the product manager stops putting tickets in because he
can't figure out how to do it, and the developers get afraid of putting time
on tickets because you try to subtract an hour that you worked on it and
somehow end up adding 5 hours, and the remotes complain that it takes 40
seconds to create a ticket, etc.

There are so many issue tracking systems out there because: THEY ALL SUCK!

~~~
pfranz
Really? Maybe you need a larger company to manage things like this; but at one
place where we switched to Jira we wrote integration into our GUI apps for
users to create tickets (and automatically log contextual info), and created
very simple "create ticket" screens in Jira itself.

The best part was being able have end users open up a ticket wherever they
were most comfortable and it could get routed to the appropriate department
without losing any history (i.e. open a ticket because of an error message in
an app, but get routed to hardware to replace a video card or driver). We went
from having 5 separate ticketing systems (a few home built) to Jira.

It always felt like you could abstract the complexity if you needed, but the
power was there if necessary. But I have no idea what was involved with
setting up and managing Jira.

The last place I worked we co-opted another app and used it for issue
tracking. Search and discoverability was so poor that most everyone used their
email to find any tickets that weren't assigned to them.

I find it weird that companies can use GitHub exclusively for issue tracking.
Not just that it's so bare bones, but many of the things that have tickets
aren't for a specific software project. I guess they use different ticketing
systems for different departments?

~~~
specialist
_" we wrote integration into our GUI apps for users to create tickets..."_

Very cool.

------
abritinthebay
Disagree. Maybe for small projects with small teams and simpler workflows but
I've found the exact opposite.

I _love_ GitHub, and it's issues system is great for specific issue management
for specific projects/modules. It could be better, but it's pretty solid.

However - once you get into wider project management which has multiple
modules/repos under it then it's _functionally useless_ for managing issues.
No visibility across repos.

Nor should there be - it's not what it's trying to solve.

Take my companies case: we use GitHub a _lot_ but we also use Jira, and they
work _really well_ together. We use a (forked) version of GitFlow to create
branches and link them to the JIRA task and when we create a PR (to be
reviewed via Github) it notes what issue it's related to.

Github's diffing, commenting, and so on, still used as normal. It's great.

For for bug tracking, story breakdowns, burn down, spring planning, etc etc -
this is Jira's bread and butter (after you configure it at least). And these
are not things GitHub is going to be good at - and it shouldn't try!

Different use cases. Using one to do what the other does would be horrible.

Compare with some OSS projects I run that _don 't_ need all I mentioned above
and yes, obviously, I use GitHub exclusively... because it's the best tool for
the job.

------
1_800_UNICORN
As far as I can tell, Jira sells well to enterprises because it focuses on
features that enterprises like (lots of accountability and metrics and charts
and graphs and shit, extremely configurable). But it doesn't sell well to
developers on the ground because it's slow, its extreme configurability ends
up screwing with developer productivity, and it's not a pleasant or easy
interface to deal with.

I don't foresee the end of Jira any time soon, but I do think that they will
go the way of other enterprise bloatware eventually.

------
pureprotein
Github shouldn't focus on making issues better, for the same reason why Github
is eating Jira.

Like OP observed, Github is eating _despite_ their investment in issues. If
issues was a stronger pulling factor the opposite should be happening.

Which means, Github should invest their time and energy more on code side
instead of issues. Improving issues will be definitely better but is not the
crucial factor.

I think it's because the "issues" are ephemeral whereas the code and the
community around the code has significantly greater value.

~~~
x1798DE
I don't see how this follows. If I am selling cars that are incredibly cheap,
safe, reliable and comfortable but invariably smell like wet dog, should I
focus all my efforts into the parts I'm already doing well just because the
cat is selling well, or should I try to get rid of the wet dog smell to try to
capture even more of the market?

~~~
pureprotein
To use your analogy, if I am selling cars that are incredibly cheap, safe,
reliable and comfortable, and people are buying my car over other cars that
smell like rainbows and unicorns, there probably is some unique value I'm
providing here.

Since we're talking about startups, if I were to make a decision I would
rather focus the hell out of my strength than trying to invest my limited
resources in improving my weakness.

Also, "smell like wet dog" is a bit too extreme analogy don't you think? For
most people I think Github issues is good enough. It would be more like
"doesn't have the best scent ever but it's good enough"

------
voycey
If I'm working solely within a programming team then Github issues works fine
for tracking bugs and features. It's when you need to communicate with teams
outside of the code that JIRA really shines, everyone in the company has an
account - if you need someone to do something then the ticket gets assigned to
them!

------
Legion
Atlassian's cloud-hosted JIRA performed so poorly with even an empty account
and empty projects that I thought something had to be wrong the two times we
tried using it.

I imagine it's a problem you can throw resources at when hosting it yourself,
but I could not get over how poor the experience was.

~~~
farkas
When was this? We've made HUGE improvements to the performance of both JIRA
and Confluence online recently.

~~~
tropo
Don't know about him, but for me: Confluence 5.6.3 and JIRA 6.3.6 (with Agile
6.6.11) and Bamboo 5.8.1 on an air-gapped secure network.

It's bad. We mostly blame the use of Java.

It looks like we're sticking with JIRA for now.

Confluence is kind of on the way out. We have numerous wiki servers. The big
one, and all the new ones, run MediaWiki. We aren't running around converting.
In addition to performance issues, the lack of standard (sorry, but MediaWiki
sets the standard) wiki markup syntax hurts badly. The situation for importing
a table is laughably awful, with stuff (CSV, tab delimited, space delimited,
space padded, etc.) apparently needing to be first imported into a
spreadsheet. The lack of category support (as seen on MediaWiki) is pretty
much a deal breaker by itself. Instead you force something like a directory
structure. Well, MediaWiki categories can be nested, but pages can also go in
multiple categories. Confluence lacks that.

Bamboo... first of all, OMG the web interface is slow. I'm told that the
licensing gets crazy past 10 build boxes. This causes issues with access
controls, particularly when air-gapped (disconnected) networks are required.
We need multiple instances just for that. Add in the need to build on several
different versions of each OS, and it gets really really painful. I think we
may be ditching this one, but it's duct taped together well enough for right
now.

------
breakingcups
And yet Gitlab is eating GitHub according to this other article.. What an
empty baseless article.

We use Jira (self-hosted) and I can not imagine ever switching to Github
Enterprise the featureset doesn't even compare.

------
k__
The only people I know, that have good things to say about Jira are working
for companies that sell software made for Jira.

