GitHub is eating Jira(movingfulcrum.com)
movingfulcrum.com
GitHub is eating Jira
http://movingfulcrum.com/github-is-eating-jira/
22 comments
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.
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.
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.
We moved to it (edit: JIRA) recently from Trello, a story almost ubiquitous among young, growing companies in my community. (So there's my anecdotal evidence.) When we finally hired a project manager/producer, we tightened up our processes and after much searching, landed on JIRA, no matter how much we wanted to find something better.
I can't imagine Github is eating into any of JIRA's core users.
FWIW, Github Issues didn't make it past the first round of trials in our company, but I'm very happy it exists for (and for its integration with) the few open source projects I own/contribute to.
Edit: the article says moving to Github Issues, and then talks about code hosting. We host all our non-open-source code with Wildbit Beanstalk (http://beanstalkapp.com) and use JIRA for project management/issue tracking. The article is a bit confused.
I can't imagine Github is eating into any of JIRA's core users.
FWIW, Github Issues didn't make it past the first round of trials in our company, but I'm very happy it exists for (and for its integration with) the few open source projects I own/contribute to.
Edit: the article says moving to Github Issues, and then talks about code hosting. We host all our non-open-source code with Wildbit Beanstalk (http://beanstalkapp.com) and use JIRA for project management/issue tracking. The article is a bit confused.
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!
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!
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?
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?
"we wrote integration into our GUI apps for users to create tickets..."
Very cool.
Very cool.
"There are so many issue tracking systems out there..."
Because every Dev/QA/Test team is a unique snowflake. JIRA tries to be all things to all people, to support all the mutant chaotic psychotic use cases, so it becomes nothing to everyone. Just like the enterprisey CRM, ERP, etc systems we all hate so much.
I had high hopes for FogBugz; I like that it's opinionated. But I haven't yet had the juice to procure it. (Atlassian won the marketing mindshare battle.)
Next time I'm in charge of QA, I'll be rolling my own tracker, again. To better support our workflow directly.
I've long wondered what a WYSIWYN tracker would look like. Maybe a HyperCard and wiki hybrid with a versionable schema (to reduce costs of change, because all processes evolve if permitted). Alas, I haven't had the gumption to make such an elegant beast.
Because every Dev/QA/Test team is a unique snowflake. JIRA tries to be all things to all people, to support all the mutant chaotic psychotic use cases, so it becomes nothing to everyone. Just like the enterprisey CRM, ERP, etc systems we all hate so much.
I had high hopes for FogBugz; I like that it's opinionated. But I haven't yet had the juice to procure it. (Atlassian won the marketing mindshare battle.)
Next time I'm in charge of QA, I'll be rolling my own tracker, again. To better support our workflow directly.
I've long wondered what a WYSIWYN tracker would look like. Maybe a HyperCard and wiki hybrid with a versionable schema (to reduce costs of change, because all processes evolve if permitted). Alas, I haven't had the gumption to make such an elegant beast.
> Next time I'm in charge of QA, I'll be rolling my own tracker, again. To better support our workflow directly.
What is the workflow that you use? Is it supported by JIRA today? If it is - what would need to have to happen in JIRA to be something you'd support?
We're always keen to improve.
Scott, CEO Atlassian
What is the workflow that you use? Is it supported by JIRA today? If it is - what would need to have to happen in JIRA to be something you'd support?
We're always keen to improve.
Scott, CEO Atlassian
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.
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.
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.
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.
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.
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.
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?
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"
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"
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!
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.
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.
When was this? We've made HUGE improvements to the performance of both JIRA and Confluence online recently.
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.
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.
Same experience. Could not believe how slow it was.
Cloud-hosted JIRA is missing a lot of features compared to host-yourself JIRA.
For one, the cloud version doesn't support LDAP or any other directory schemes for controlling user accounts. That's a big deal for companies who have gotten big enough to start using directory to control access to everything, which is hopefully every company with over 100 employees.
For one, the cloud version doesn't support LDAP or any other directory schemes for controlling user accounts. That's a big deal for companies who have gotten big enough to start using directory to control access to everything, which is hopefully every company with over 100 employees.
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.
We use Jira (self-hosted) and I can not imagine ever switching to Github Enterprise the featureset doesn't even compare.
The only people I know, that have good things to say about Jira are working for companies that sell software made for Jira.
If you can show me atlassian profit loss (hint there isn't any: https://investors.atlassian.com/financials-and-filings/finan...) then I would believe this.