6 ms·

> While it is still used by many tech businesses (including the author’s), it has no real network effect — that is, users can switch to a competitor product lik

> While it is still used by many tech businesses (including the author’s), it has no real network effect — that is, users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system). Lol. At some companies, Jira workflows literally run the whole company. At my prev job, prod deployments were tightly linked to Jira.

zelos 4y ago
Yes - JIRA is almost a textbook example of lock in. Moving a large company's workflow would mean months of disruption.
- zeusk 4y ago
  I helped a prior employer move to github and asana through JIRA's own APIs. It's actually not that hard and the entire engineering group was very cheerful of the change.
  - threeseed 4y ago
    Be curious what the size of the engineering team and company was. Asana is great for SMBs but for larger developer teams it lacks a lot of features and integrations.
    - daniel_iversen 4y ago
      (Work at Asana so I might be biased) While Jira may have some unique features for developers, one of Asana’s selling points is how it allows non-homogenous teams (incl whole companies) to work together (and by themselves within individual teams) on a variety of different kinds of work (projects, processes, loose day to day tasks etc). And as for scale we have many customers with thousands of users (one tech customer of ours has 100,000+ users on Asana - most of them I’m sure would be product teams).
  - zelos 4y ago
    Really? Was it easy enough to define mappings between all the various fields/ticket types etc? I guess you could do it per-team across an organisation. It always seems hard enough to get information out of JIRA using JIRA when I watch our PO in planning meetings.
    - zeusk 4y ago
      Yup, there was some mess around inexact mapping so we had our own conflict resolution and definition of what and how to interpret respective fields. Honestly, JIRA easily has one of the most sluggish and horrid developer experience so the bar wasn't too high to begin with. Visual Studio Online / Azure DevOps is far better than JIRA ecosystem imo.
- maccard 4y ago
  Any tool has lock in. How much work do you think would be involved in moving from perforce to git, or from Bamboo to CircleCI?
  - hoseja 4y ago
    Not if there is an open protocol with multiple conforming implementations.
  - alxlaz 4y ago
    I was (a very small, and only part-time) part of a team that did a migration from a Perforce-era VCS to git. It was about 6 weeks of 100% background work -- as in, we prepared cheat sheets, changed or rewrote relevant parts of the CI and deployment chain, while everyone in the company kept using the old VCS. Then it took about 36 hours to move the relevant code bases (a few dozen repositories, some of them 20+ years old) over to git, including the entire commit history. This was pretty slow. It could have probably be done faster but we figured, since we only do it once, we don't need to invest too much time. We scheduled it on Saturday morning so it would be done by Sunday afternoon and we had some time to test it before Monday hit the earliest timezones. We had a backup plan in place in case it didn't work but it wasn't necessary. The two repos were automatically synced for a while, to allow people who had started work on something on, say, Friday morning, to commit their changes to the old repos, rather than have to replay their work on the new ones. After that the old repos remained read-only, but we preserved them because, obviously, our issue tracker had twenty years' worth of references to old VCS revision numbers. So it took about 6 weeks of indulgently part-time work (our infra team worked several hours a day on this, I worked... about an hour or so a week?) to plot this daring plan, and about two days to make it happen. The total amount of work disruption was likely non-zero but certainly small enough that most people didn't complain of anything other than having to learn git. I can't say about Bamboo to CircleCI but, having gone through one of these, I can say with 100% confidence that if you start out right -- that is, your existing repository is not a mess of stale branches and weird merges -- and you don't go about moving fast and breaking things, moving from even an ancient revision control system to git is not really apocalyptic.
    - 4y ago
threeseed 4y ago
The thought of running a 10,000+ development team using Basecamp is hilarious in its insanity. Because that is where Jira primarily plays. In enterprise companies where it's rolled out across the organisation with tentacles firmly embedded into almost every process and system. And whilst people continue to criticise Jira it continues to grow because in reality it competes with products like Rally not Asana. And there really isn't anything out there that can offer the same level of customisability and flexibility.
- Juliate 4y ago
  Indeed Jira scales a lot (although being slow) and is well customisable and flexible. Its plugin system is also great (although a better documentation of how to develop/maintain one, and of their APIs would grealy help). But in the meantime, it requires increasing discipline and regular revampings of internal processes across dev, product, market teams, and that's a lot of energy to burn to make it "work" across an org. Even more when you have people that are for very strict and precise adherence to processes. Whereas a less flexible, good enough system could help funnel the same energy towards something more productive than just internal compliance for the sake of it.
  - threeseed 4y ago
    Which is why Jira continues to sell so well. You simply can't force one way of working on larger companies even if that way is undisputedly the right way. Because a lot of people will need to sign off on which tool to purchase and each of them are special geniuses with their own special genius way of working.
    - Juliate 4y ago
      Well, time will tell. I'm not opposing a single Jira methodology to a myriad of other ones (tools or processes). I'm saying that Jira, without being constantly challenged for what it is[1] creates its own growing and tiring bureaucracy because companies (even large ones) cannot agree on a right way to work (but will add piles over piles of bureaucracy). [1] exactly like what Agile methodologies, or some certifications are; where now it feels like almost no one remembers/knows how to organize teams _without_ resorting to anything that Agile-thinking has tainted. It somehow relates to the fact that, in some companies, more energy and money is burnt over how to organize the work rather than doing the work itself. And it definitely shows.
chii 4y ago
> (other than the initial hassle of switching to a new system). that's doing a lot of work in that sentence!
rmbyrro 4y ago
> other than the initial hassle of switching to a new system Is like saying: "people can move overseas with minimal cost (other than shitloads of migration bureaucracy, frequent flying to meet family, put their entire furniture on top of a cargo ship)
- yen223 4y ago
  And, since this a thread about JIRA, a lot of bureaucracy
- threeseed 4y ago
  More like trying to remove an invasive cancer that has spread to all parts of your body whilst you're still needing to move around, be productive and live your life.
  - dx034 4y ago
    I'd say that for many large companies, Jira is better than the alterntive of having multiple systems that need to be kept in sync. Steering any large company will be a mess, no software will ever make that easy. And any software designed to be that flexible will end up being slow eventually.
    - rmbyrro 4y ago
      I guess the cancer is analogous to JIRA itself, not to the migration of JIRA. Migrating out of JIRA is analogous to "trying to remove an invasive cancer".
ArnoVW 4y ago
While it is true that Jira is "sticky", the statement was that it did not have a network effect. MS Word, Facebook, WhatsApp, Visa, they all have network effects: every user you add makes your product more compelling, thus creating a virtuous circle. You need to buy their product because other people have their product.
- codeyperson 4y ago
  What network effects does MSWord have?
  - iddan 4y ago
    You couldn't open a MSWord file without MSWord.
    - deleted 4y ago
      [deleted]
  - angrygoat 4y ago
    Everyone else is using it to write documents, email around drafts, collaboratively edit via OneDrive; sure you can use an alternative, but nobody will want to see a format but .docx, so your alternative is almost guaranteed to be worse than or equivalent to Word. If your alternative stuffs up the document's formatting you become seen as a pain in the neck. So it's just easier to use Word.
  - matwood 4y ago
    Every contract I've received or sent for red-lining uses Word and change tracking. I'm sure exceptions exist, but every lawyer I've dealt with uses Word as the defacto standard for contract negotiations.
- bryanrasmussen 4y ago
  The network effect of Jira is obviously at the department level; dept. head A mandates Jira. User B gets moved to new dept. C, we need some sort of project management tool - hey B what did you use when you were working for A, oh A likes using Jira, I didn't like it much but it's ok I guess. Ok folks, let's use Jira! Dept. Head A moves to Dept. D, hey everyone we are going to start using Jira. Dept D. is being merged with Dept. E, Dept and new Dept. Head J is joining. E is using some open source Kanban solution based on CouchDB, hmm, let's go to Jira - other departments are also using it and then we can get rid of the CouchDB thing! In point of fact where network effects of Jira is concerned, I have put some effort into learning JQL and setting up my own dashboards, so when you give me one of the competitors I get grouchy. I prefer Jira or Trello - also owned by Atlassian iirc?
hoseja 4y ago
Funny how the network effect is rephrased in terms of cost of switching, instead of the more benign word of mouth etc.
gonzo41 4y ago
Coupling, it's a constant scourge all over in software. Whilst I LOVE to crap on Jira, it has brought some magnitude of order and civility to the PMO's and at least created a familiar work environment for people. God help me If I ever have to go back to word docs and sharepoint to manage project work.
yellow_lead 4y ago
At my old company, they had two annoying jira workflows management wanted to tie in to the dev process 1) When the user wants to merge to master, at least one of the commit messages must reference a valid Jira ticket. 2) A Jira plugin was installed such that when tests were run in CI, a jira ticket was created to record the result (pass/fail). This somehow ticks a SOC compliance box
- wizofaus 4y ago
  1) sounds pretty reasonable and standard to me, though a backdoor is usually necessary for PRs that are just to fix a build-blocking issue due a bad merge e.g. Agree 2) is stupid, why would you need a ticket for a passing build? And unless you have a super stable CI system a decent % of failures are transitory and don't need tracking - but if your master branch fails to build on retry an auto created blocker ticket makes sense.
yunohn 4y ago
>> with minimal cost (other than the initial hassle of switching to a new system) The first part does not realistically connect to the second part. Surely the author is aware that switching to new systems is actually quite expensive monetarily and operationally - definitely not “minimal”?
MarkMarine 4y ago
How’s that working when Jira is down for almost a week and there is next to no feedback about the outage
janee 4y ago
> users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system). My experience tells me the complete opposite of this statement. Regardless of the the workflows, automation and whatnot there are tons and tons of IP hidden in tickets and over a long enough period references to them end up scattered all over your tools, commits, documents, wikis, IM, email, etc. etc. When you move ticketing providers it's very likely you can't correctly migrate all of your existing data into the new system without breaking or losing some of it. I detest trying to figure out why a certain code change was made, looking at the commit message only to find a reference to link to a dead ticket. I'm not for or against Jira, but moving ticketing systems does not come at a "minimal cost" in my opinion and needs careful consideration and motivation.
gomox 4y ago
I was about to write the exact same comment - quote the bit where they say Jira has no network effects and add "LOL" after it. How out of touch can you be with the stickiness of enterprise SaaS, and still write financial commentary?

zelos 4y ago

Yes - JIRA is almost a textbook example of lock in. Moving a large company's workflow would mean months of disruption.

zeusk 4y ago
I helped a prior employer move to github and asana through JIRA's own APIs. It's actually not that hard and the entire engineering group was very cheerful of the change.
- threeseed 4y ago
  Be curious what the size of the engineering team and company was. Asana is great for SMBs but for larger developer teams it lacks a lot of features and integrations.
  - daniel_iversen 4y ago
    (Work at Asana so I might be biased) While Jira may have some unique features for developers, one of Asana’s selling points is how it allows non-homogenous teams (incl whole companies) to work together (and by themselves within individual teams) on a variety of different kinds of work (projects, processes, loose day to day tasks etc). And as for scale we have many customers with thousands of users (one tech customer of ours has 100,000+ users on Asana - most of them I’m sure would be product teams).
- zelos 4y ago
  Really? Was it easy enough to define mappings between all the various fields/ticket types etc? I guess you could do it per-team across an organisation. It always seems hard enough to get information out of JIRA using JIRA when I watch our PO in planning meetings.
  - zeusk 4y ago
    Yup, there was some mess around inexact mapping so we had our own conflict resolution and definition of what and how to interpret respective fields. Honestly, JIRA easily has one of the most sluggish and horrid developer experience so the bar wasn't too high to begin with. Visual Studio Online / Azure DevOps is far better than JIRA ecosystem imo.
maccard 4y ago
Any tool has lock in. How much work do you think would be involved in moving from perforce to git, or from Bamboo to CircleCI?
- hoseja 4y ago
  Not if there is an open protocol with multiple conforming implementations.
- alxlaz 4y ago
  I was (a very small, and only part-time) part of a team that did a migration from a Perforce-era VCS to git. It was about 6 weeks of 100% background work -- as in, we prepared cheat sheets, changed or rewrote relevant parts of the CI and deployment chain, while everyone in the company kept using the old VCS. Then it took about 36 hours to move the relevant code bases (a few dozen repositories, some of them 20+ years old) over to git, including the entire commit history. This was pretty slow. It could have probably be done faster but we figured, since we only do it once, we don't need to invest too much time. We scheduled it on Saturday morning so it would be done by Sunday afternoon and we had some time to test it before Monday hit the earliest timezones. We had a backup plan in place in case it didn't work but it wasn't necessary. The two repos were automatically synced for a while, to allow people who had started work on something on, say, Friday morning, to commit their changes to the old repos, rather than have to replay their work on the new ones. After that the old repos remained read-only, but we preserved them because, obviously, our issue tracker had twenty years' worth of references to old VCS revision numbers. So it took about 6 weeks of indulgently part-time work (our infra team worked several hours a day on this, I worked... about an hour or so a week?) to plot this daring plan, and about two days to make it happen. The total amount of work disruption was likely non-zero but certainly small enough that most people didn't complain of anything other than having to learn git. I can't say about Bamboo to CircleCI but, having gone through one of these, I can say with 100% confidence that if you start out right -- that is, your existing repository is not a mess of stale branches and weird merges -- and you don't go about moving fast and breaking things, moving from even an ancient revision control system to git is not really apocalyptic.
  - 4y ago

threeseed 4y ago

The thought of running a 10,000+ development team using Basecamp is hilarious in its insanity. Because that is where Jira primarily plays. In enterprise companies where it's rolled out across the organisation with tentacles firmly embedded into almost every process and system. And whilst people continue to criticise Jira it continues to grow because in reality it competes with products like Rally not Asana. And there really isn't anything out there that can offer the same level of customisability and flexibility.

Juliate 4y ago
Indeed Jira scales a lot (although being slow) and is well customisable and flexible. Its plugin system is also great (although a better documentation of how to develop/maintain one, and of their APIs would grealy help). But in the meantime, it requires increasing discipline and regular revampings of internal processes across dev, product, market teams, and that's a lot of energy to burn to make it "work" across an org. Even more when you have people that are for very strict and precise adherence to processes. Whereas a less flexible, good enough system could help funnel the same energy towards something more productive than just internal compliance for the sake of it.
- threeseed 4y ago
  Which is why Jira continues to sell so well. You simply can't force one way of working on larger companies even if that way is undisputedly the right way. Because a lot of people will need to sign off on which tool to purchase and each of them are special geniuses with their own special genius way of working.
  - Juliate 4y ago
    Well, time will tell. I'm not opposing a single Jira methodology to a myriad of other ones (tools or processes). I'm saying that Jira, without being constantly challenged for what it is[1] creates its own growing and tiring bureaucracy because companies (even large ones) cannot agree on a right way to work (but will add piles over piles of bureaucracy). [1] exactly like what Agile methodologies, or some certifications are; where now it feels like almost no one remembers/knows how to organize teams _without_ resorting to anything that Agile-thinking has tainted. It somehow relates to the fact that, in some companies, more energy and money is burnt over how to organize the work rather than doing the work itself. And it definitely shows.

chii 4y ago

> (other than the initial hassle of switching to a new system). that's doing a lot of work in that sentence!

rmbyrro 4y ago

> other than the initial hassle of switching to a new system Is like saying: "people can move overseas with minimal cost (other than shitloads of migration bureaucracy, frequent flying to meet family, put their entire furniture on top of a cargo ship)

yen223 4y ago
And, since this a thread about JIRA, a lot of bureaucracy
threeseed 4y ago
More like trying to remove an invasive cancer that has spread to all parts of your body whilst you're still needing to move around, be productive and live your life.
- dx034 4y ago
  I'd say that for many large companies, Jira is better than the alterntive of having multiple systems that need to be kept in sync. Steering any large company will be a mess, no software will ever make that easy. And any software designed to be that flexible will end up being slow eventually.
  - rmbyrro 4y ago
    I guess the cancer is analogous to JIRA itself, not to the migration of JIRA. Migrating out of JIRA is analogous to "trying to remove an invasive cancer".

ArnoVW 4y ago

While it is true that Jira is "sticky", the statement was that it did not have a network effect. MS Word, Facebook, WhatsApp, Visa, they all have network effects: every user you add makes your product more compelling, thus creating a virtuous circle. You need to buy their product because other people have their product.

codeyperson 4y ago
What network effects does MSWord have?
- iddan 4y ago
  You couldn't open a MSWord file without MSWord.
  - deleted 4y ago
    [deleted]
- angrygoat 4y ago
  Everyone else is using it to write documents, email around drafts, collaboratively edit via OneDrive; sure you can use an alternative, but nobody will want to see a format but .docx, so your alternative is almost guaranteed to be worse than or equivalent to Word. If your alternative stuffs up the document's formatting you become seen as a pain in the neck. So it's just easier to use Word.
- matwood 4y ago
  Every contract I've received or sent for red-lining uses Word and change tracking. I'm sure exceptions exist, but every lawyer I've dealt with uses Word as the defacto standard for contract negotiations.
bryanrasmussen 4y ago
The network effect of Jira is obviously at the department level; dept. head A mandates Jira. User B gets moved to new dept. C, we need some sort of project management tool - hey B what did you use when you were working for A, oh A likes using Jira, I didn't like it much but it's ok I guess. Ok folks, let's use Jira! Dept. Head A moves to Dept. D, hey everyone we are going to start using Jira. Dept D. is being merged with Dept. E, Dept and new Dept. Head J is joining. E is using some open source Kanban solution based on CouchDB, hmm, let's go to Jira - other departments are also using it and then we can get rid of the CouchDB thing! In point of fact where network effects of Jira is concerned, I have put some effort into learning JQL and setting up my own dashboards, so when you give me one of the competitors I get grouchy. I prefer Jira or Trello - also owned by Atlassian iirc?

hoseja 4y ago

Funny how the network effect is rephrased in terms of cost of switching, instead of the more benign word of mouth etc.

gonzo41 4y ago

Coupling, it's a constant scourge all over in software. Whilst I LOVE to crap on Jira, it has brought some magnitude of order and civility to the PMO's and at least created a familiar work environment for people. God help me If I ever have to go back to word docs and sharepoint to manage project work.

yellow_lead 4y ago

At my old company, they had two annoying jira workflows management wanted to tie in to the dev process 1) When the user wants to merge to master, at least one of the commit messages must reference a valid Jira ticket. 2) A Jira plugin was installed such that when tests were run in CI, a jira ticket was created to record the result (pass/fail). This somehow ticks a SOC compliance box

wizofaus 4y ago
1) sounds pretty reasonable and standard to me, though a backdoor is usually necessary for PRs that are just to fix a build-blocking issue due a bad merge e.g. Agree 2) is stupid, why would you need a ticket for a passing build? And unless you have a super stable CI system a decent % of failures are transitory and don't need tracking - but if your master branch fails to build on retry an auto created blocker ticket makes sense.

yunohn 4y ago

>> with minimal cost (other than the initial hassle of switching to a new system) The first part does not realistically connect to the second part. Surely the author is aware that switching to new systems is actually quite expensive monetarily and operationally - definitely not “minimal”?

MarkMarine 4y ago

How’s that working when Jira is down for almost a week and there is next to no feedback about the outage

janee 4y ago

> users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system). My experience tells me the complete opposite of this statement. Regardless of the the workflows, automation and whatnot there are tons and tons of IP hidden in tickets and over a long enough period references to them end up scattered all over your tools, commits, documents, wikis, IM, email, etc. etc. When you move ticketing providers it's very likely you can't correctly migrate all of your existing data into the new system without breaking or losing some of it. I detest trying to figure out why a certain code change was made, looking at the commit message only to find a reference to link to a dead ticket. I'm not for or against Jira, but moving ticketing systems does not come at a "minimal cost" in my opinion and needs careful consideration and motivation.

gomox 4y ago

I was about to write the exact same comment - quote the bit where they say Jira has no network effects and add "LOL" after it. How out of touch can you be with the stickiness of enterprise SaaS, and still write financial commentary?