The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products. We have to assume that there are problems of a similar nature in their cloud service, which is way more of a problem considering the number of orgs that depend on the JIRA SaaS offering.
Maybe the founders could have used some of that time spent planning a tunnel between their side-by-side $100M houses, or engaged in Twitter rants, to actually bother delivering value to customers. It’s only a matter of time before this product suite is disrupted, and it might represent one of the most obvious low-hanging opportunities in our entire industry.
I still remember being in line at a WWDC a few years back, overhearing someone ask a developer, “where do you work?” When the developer responded with “HipChat,” the other person immediately chuckled and said, “oh — Atlassian... I’m sorry” — and then everyone around them also started laughing. It’s amazing that this company continues to fall up, and that the founders have taken on roles as the ruling digital gurus of Australia (shows you why it’s so easy for the government to run circles around the local tech industry and pass whatever laws they want).
> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products.
Regardless of what one thinks about Atlassian, this is a completely ridiculous bullshit statement, and anyone who works in the world of business software knows it.
I don't think there is a company out there that hasn't had critical CVEs, nor most major open source projects, either.
Microsoft had a recent vulnerability in their Azure Cosmos DB product that left thousands of customers' data unprotected. Google has released multiple patches to Chrome in the past month.
If you demand you'll only use products from companies or open source projects that have never had a major CVE, you'll be writing a lot of your own software that probably has even worse security.
Any sufficiently complicated product will eventually have major CVEs, as you say. Anyone having hosted Atlassians product know that these products are nothing but garbage fires on the inside, as the commenter above said.
Both of these statements are true and not mutually exclusive in any way.
If all products have CVEs, and CVEs are a form of defect, then it follows quite naturally that highly defective products will have CVEs, likely more than less defective products.
So yes. Yes it does. Unless you meant that CVEs imply garbage code, in which case I think you read the comment wrong.
This is a complete misunderstanding caused by not readinf the first half of the first sentence of the comment.
The full sentence:
> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products.
I.e., because the software is available for on-prem deployment, we have experience deploying, managing and debugging it, and therefore know that it is garbage, and we can apply this knowledge to conclude that their cloud offering is garbage.
It does not say the product is garbage because of a CVE.
All products will have defects that are not CVEs, hopefully by a large margin.
But every sufficiently complicated product will have defects of this type, and a higher probability of defects does increase the probability of CVEs.
So, it follows in practice, as can be seen by looking at CVE rates from projects with high defect rates (web browsers, kernels, ...) vs projects with low defect rate.
Note that defect rate differences can be caused by multiple things.
> Would you care to give us alternatives, for example, to the JIRA bug tracker
Paper.
An Excel spreadsheet shared on a Windows for Workgroups share drive.
Carrier pigeon.
Quitting software to become a llama herder.
Seriously, though, after over two decades of using different tracking systems I think that the real alternative to stuff like Jira is to not go there. You may think that you need all those bells and whistles, but you really don't. What you actually need is the simplest possible issue tracking system you can get away with. All you really need is a prioritised list of issues, and a list of who is working on which issues now. ‘Kanban’ boards get pretty close.
I don't disagree that Atlassian programs are generally bloated, but it is interesting to see everyone jumping at JIRA when its Confluence with the CVE...
JIRA is too many things to too many people - in the quest to be everyone's bug tracker, they wrote (badly) in the whole kitchen sink. This is a general issue with most software, though. Especially big software.
You cannot have complex capable software that is also simple. That's an oxymoron. You can have complex software which works, but it is difficult to get there, and keep it there. There is simply too much that can go wrong that over time, it almost must go wrong.
Keeping everything 'simple' is not an alternative - the world is complex and so even a bunch of simple things, when put together, make something complex. Think unix shell scripts which can be so much sphagetti. The unix philosophy is to keep things simple, and yet ignoring the complexity leads to its own complexity.
That's the real 'terrible engineeing practices' which get down Atlassian and everyone else's programs.
Someone said 'use paper' or 'quit and become a llamma herder' - these seem simple but again, paper burns, shepherds get shot or held up by drug gangs.
All to say, I don't think JIRA is actually that bad. There could be worse products, there could be better. But it would exceedingly difficult to make something simple which also served everybody.
ZenHub! I love, as an engineer, that it layers on top of GitHub issues. So, in my general day to day I never leave GitHub.com or GHE, while project managers get all their shiny toys in ZenHub that plays nicely with GitHub issues.
Pivotal Tracker. I've found it to be a much more productive tool, and teams using it typically move alot faster and are far happier than those using Jira.
> Kiln was also a great product and allowed for using both Git and Mercurial. It was way better than anything else at the time, but lost out to Github.
I used both FogBugz and Kiln at a previous employer, and I really liked FogBugz, but we had nothing but problems with Kiln. We had a fairly large team (maybe 75-100 people) and a good sized project (maybe 300k lines), and it was painfully slow to do anything in Kiln and it was down/broken at least once a month. It wasn't so bad early on when we were small, but it didn't scale with us very well.
First you need a fire starter, which in this case must be made out of bills valued 100 USD each or greater. It'll take quite a few to light the Datacenter licenses that are the now the only on-prem tier on fire...
My point is that it is experience acquired from managing these for a decade. If you wish to acquire this experience you need to run it, which is now even costlier than it used to be.
I don’t disagree with what you’re saying about software having ongoing vulnerability issues. But, that’s exactly what the problem is with communications-centric solutions that don’t offer strong data security protections such as end-to-end encryption: you’re always one CVE away from having your company’s data exposed. And, in this specific case, there is a MAJOR difference between Chrome getting owned, and the program that hosts all of a company’s internal communications concerning, among other things, known vulnerabilities in their software.
Think about that for a second. If someone finds a vulnerability in JIRA, they don’t just find a vulnerability in that software: they’ve got access to support tickets, issue tracking, etc about lots of vulnerabilities in lots of software. That’s a big deal.
The fact that the US government had to step in and say PLEASE TAKE THIS SERIOUSLY, rather than Atlassian going into a Code Red situation, shows that they just don’t take the level of responsibility they’ve been given as seriously as is required for what they’re doing. This isn’t just some lousy app having a CVE. This is the keys to the kingdom for a lot of very critical software. This is systemic risk. The problem isn’t the code, it’s the culture.
If you “work in the world of business software” and you think that’s a “complete bullshit statement,” I really hope you don’t work on anything for which such systemic risk is possible. Because, to turn your statement back on you, that’s a complete bullshit way to treat the responsibility you have for the data with which you’ve been trusted. Go build a social media app or an online shopping site or something, and stay out of critical systems that can create cascading vulnerabilities.
For people who have the Atlassian Cloud offering this is not a problem and has been fixed. The only people who are impacted are the one who host Confluence themselves. There isn't much that Atlassian can do except that tell them to update the software.
If you are maintaining the software of someone else and this software is exposed to the internet that's your responsibility to update the software. If you want your service to be available from the web and have good security, use the cloud offering, that's what it's for.
And if you don't want to use external software to manage your internal knowledge, then create some shared windows folders that nobody use and quickly becomes a mess. What alternative do your propose ?
> and stay out of critical systems that can create cascading vulnerabilities
Oh, you mean like Microsoft and Google in the examples I gave?
Why are you changing the goal posts? Your original statement was that this issue is evidence that "everyone is now aware of the awful engineering practices that underpin their products." My clear argument is that this is not the case, as lots of companies with systemically critical software also have bugs of this magnitude, or more.
Much as I hate everything Atlassian touches (although Portfolio was pretty useful as a stand-alone tool if you kept it far away from JIRA), It’s not like MS Office or Sharepoint have never had vulnerabilities..
> don’t offer strong data security protections such as end-to-end encryption
Imagine being so naive as to think that documentation would be improved by e2e encryption. It's not bad enough convincing developers to write things down, now we need to explicitly share those things with every new person who joins the team?
"Sorry, we can't fix your bug for 6 weeks, Bob's on paternity and the fix is documented on his page".
> MAJOR difference between Chrome getting owned, and the program that hosts all of a company’s internal communications
There's at best 0 difference between these things. Pop chrome, harvest tokens, access Jira. Think about that for a second. What critical company information is not accessible to someone who has arbitrary code execution in your browser.
Oh, serendipitously, the article currently directly below this one on HN is "Apple iMessage Zero-Click Hacks". So add Apple to the list of companies on your "awful engineering practices" list.
Eh? If there was a remote root exploit in Chrome, ALL your data is similarly 0wned, exfiltrated, and for sale to your enemies. EVERY computer you have used Chrome on has is now suspect, and all website data each of those compuers to will now have its data stolen and sold on hackers.ru and .ch. All my employer's business data being stolen is one thing, but all of my online banking credentials are of particular personal interest to me in staying confidential.
Interestingly I assumed (due to personal and anecdotal experience fro colleagues) it’s not a good experience and that was part of what the parent was referring to.
Coming from ClearQuest, Jira was a breathe of fresh air some years ago. We can run projects with several hundred to thousand people with it (the on prem version) without problems and UX is ok IMHO. Maybe it's easy to screw up the config?
It's slow, but so long as you don't do anything “out of the ordinary” (i.e. try to act like the average sort of person who would use Jira), it's decent enough to use. I've personally had no workflow issues, though I could tell there was something deeply wrong with the internals.
Then again, if you're only using the “ordinary” features, Jira doesn't have much advantage over any other bug tracker; Gitea can integrate with Jira just as well as with any other bug tracker, and well enough that the Jira / Confluence integration isn't necessary.
The Atlassian softwares are okay, but (from my limited experience) worse than their alternatives. On several occasions, I expected a bug, but it refreshed or redirected, and there wasn't a bug. I have found no bugs while using Jira, and not unusably many while using Confluence… but I can say the same for Gitea, GitHub, Gitlab and even Bugzilla. (Gitea's native issue tracker is actually good enough – and therefore better than Jira – for everything I ever used Jira for.)
> Jira doesn't have much advantage over any other bug tracker
Ohhh found the non power Jira user! Gitea is good enough for your org. Without knowing your requirements this is pretty much a blanket statement. Gitea is nowhere near good enough for a large engineering org.
Example: groovy integration with Jira allows an enterprise to build their own custom workflows. Like integrating with your Vcs to enforce funded work (requiring an open Jira issue in git commits). Features like this, until recently, left them in a league of their own. GitHub Actions has leveled that playing field. Gitlab and gitea can fight it out with bugzilla, but you won’t find them in most engineering orgs.
Another example: building out complex dev roadmaps ahead of time with constraints and relationships. Bridging the gap between dev, product, and project management
I can see how you jumped to the conclusion this CVE means Atlassian is nonsense, but it’s not the only take on the comment. The discussion arising from a
I’m not really sure what the point of the rant is. It’s not as if such a comment conclusion is as big of deal to reality as an idiot staying unvaccinated.
But I get it; someone is “wrong”* on the internet.
* where wrong is defined very specifically to one or a handful of particular readers but the error doesn’t rise to being a real problem for humanity
JIRA has a solid use case (if maybe breeding ground for CVEs), confluence is just a bad competitor to OneNote. Its not a wiki...it stopped being a wiki a long time ago.
There are many jira alternatives out there, from what I can tell. Why are they not disrupted already, if it’s such a low hanging fruit? (Honest question - I don’t have any personal preference)
Not just product managers. All kinds of enterprise processes decompose nicely into tickets. Arbitrary workflows, transitions, validations, custom fields, filters, and reports make it one of the most successful “no code” tools behind Excel, and then the REST API is comprehensive and well documented. At my company JIRA bots are compelling and cheap alternatives to new web UIs for internal tooling needs, surprisingly often.
How many PMs actually use those features? In my organization, for example, I don't see any reason why we should prefer Atlassian over Taiga, other than familiarity and inertia.
It isn't the set of features that makes them sticky. It is the 10% of features the lead PM can't live without, and the slightly-overlapping-but-different 10% of features the team PM's can't live without, and the slightly-overlapping-but-different 10% of features the developers can't live without, and the roll-up report features the leadership team can't live without... There has been some research into this phenomena [1]. I'm not aware of a handy term for the phenomena, would surely appreciate someone pointing me to it, and the industry recognizing it and building for it, though.
Internally in my head I call it "multiplexing feature sets". Though I never say that aloud and just give the long-winded explanation if I have to bring it up in meetings.
> ...I don't see any reason why we should prefer Atlassian over Taiga, other than familiarity and inertia.
In large-organization dynamics, never underestimate the familiarity and inertia factors. I regularly see vendors screw this up so badly. Account management teams of even large organization vendors (so they should be taking action upon this, but apparently are not) regularly have no clue what kind of massive red flag it takes to push their decade(s)-entrenched product from "man we wish this could be better" to "you really need to fix this, or we need to start looking elsewhere".
How do you tell when a customer is just kvetching and presenting empty threats, or is laying it on the line to you? Easy: the customer is happy to share with you specific details of how the product shortcomings/defects are impacting line of business processes and the business impact (ask for this under the cover of learning what the critical business impact is so your support teams can devise the most appropriate tactical technical solution for immediate partial/total relief), and is eager for live working sessions with the customer's engineers.
And understand this: rarely will a customer reveal they have switched away until it is practically finished. They want to maintain what little interim support quality they have left, until they can step off. If your account management practices engage "all hands on deck" priority support when you get wind of a competitor in the wheelhouse, then you've lost before you even started. That's why the reveal is always a shock to vendors, and always a done deal when it is shared.
The time to understand that your product and product support consumption experience for a particular set of customer needs is horribly broken is when you notice a customer requesting product support leadership engagement more than 2-3 times in a year. If you aren't tracking those engagement touch points, then I guarantee you are losing license sales. They just don't show up in the sales metrics.
No it's not easy to switch. Engineeting Organisations have invested a lot in the Jira eco system, that includes custom workflows that are understood only by a few to be able to alter them, users are productive right now with jira and nobody wants them less productive even just for a while learning another task manager. Here again the integration effort to migrate would scare any leader who would be blame for the impact on so many teams deliverables. The effort is enormous and error prone to take all the data in there, move it elsewhere, rebuild the workflow and integration configuration, while keeping track of lack of feature parity to write down an explanation before everyone complains and pre empting their request to at least provide a work around what they used to be able to do with 3 clicks. Confluence slips right in because it integrates very well with jira. Just embed a confluence page into a task, and just mention a jira task within a confluence page and you get a seamless experience. Yes we could use another wiki , and a good one as confluence is a calamity. But convenience is what organisations are after. Perfect is the enemy of the good they will say. I don't have a love for atlassian products, but they tend to do their job very well compared to the majority of the competition. You will always find one product that compares, or even is superior but overall, their product works. So here we are.
If they get plagued by further security vulnerabilities then companies handling sensitive data will concede to migrate, but it won't be simple by any means.
If you believe changing people's habits is easier than ever, it's rather the opposite. Workers are less and less inclined to learn any other way . The alternative has to be order of magnitude better than what they are using, otherwise they will resist the change. The fact is atlassian provide good to great products overall.
Except that confluence and JIRA are both so slow that you'll still be there 2 minutes later waiting for it to load. Perhaps not everybody's experience is so bad? I don't understand how anyone could consider these products convenient given how ridiculously slow they were.
We used to do refinement meetings over video call (I guess everyone is these days) inputting into JIRA, and we'd literally spend 3/4's of the call waiting for JIRA to catch up with the words I'd typed. There's bad engineering, and then there's making writing a sentence text box lag with times measures in seconds.
We use the cloud version, I've edited huge Confluence pages and it's typically very snappy. Jira likewise. Could be an under-resourced on-premise deployment?
I think they’re talking about the front-end, not the server. FWIW both Confluence and Jira are abysmally slow on my machine (new MBP) on the cloud version.
I have seen on premise issues , infrastructure can be the problem, or config. Jira cloud can also be a problem,but nothing one can do about it other than sending a ticket. I think they know what they are doing wrong with certain "low value" subscriptions.
I use the cloud version also. While Jira doesn't have any issues, editing Confluence pages can be a right pain. It is constantly "losing my connection" and prevents editing until it's happy again. There's no connection issues present, unless they're at Atlassian's end.
Watching the network tab, all I see is a requests to `bayeux-sync1` endpoint that take 5 seconds or longer. There's always one of these requests hung when it enters this unresponsive mode. I suspect this is some part of the syncing system for multiple editors. Which, if true, makes it particularly hilarious to me that the entire point of this system would be to sync multiple edits, yet it won't let me keep editing while it's waiting...
Well if your organisation wants crappy project management tools and processes then there's nothing to be done. But there are plenty of alternatives out there for those who seek them.
There aren’t good integrated replacements. Any system that lacks a wysisyg interface for text is not a viable option. If copy and paste from Word doesn’t keep some of the formatting, forget it.
Our support board has customized forms. These forms create tickets that can seamlessly be moved to our scrum board once they are vetted. We use JQL to manage a lot of the boards we use. We have custom workflows for different ticket types. We use the comprehensive access controls to grant partial access to users based on custom roles.
None of this rigidly enforces our workflows (aside form access control). Instead, it streamlines sharing information across departments.
When it comes to a company wiki system, Confluence is extremely hard to beat. (I’ve use so many wiki systems. Dokuwiki is my goto.)
All of these systems use a single user account. We use single sign-on, but we don’t have a large IT department to manage the dozens of services we access every day.
I think even that would be a good attack vector against Atlassian: For them, "integration" means adding links from one product to the other. If I were to pay for an integrated suite of tools, the least I would expect is that their bloody markup languages are consistent. But because Atlassian just buys random products and then doesn't seem to ever change a single thing about them, that's not going to happen.
That’s false: Confluence went from Wikimarkup in 2008 to wysiwyg in 2010 (to big uproars); and they are uniformizing all their cloud products under the new ADF editor.
It is actually possible to want bespoke tools to do certain things. And honestly? Confluence is slow, but at least it has all the features I could want and it works.
People are like”use the shiny thing” forgetting the existing thing has, you know, stuff I actually use.
Thanks, I got you. But you didn’t really address the point of the person you responded to, then, which was that part of why this space hasn’t been disrupted to a larger degree is that Atlassian products are entrenched in many companies, and that a lot of people do want that complexity (disagree with that as you or I might).
> ... and that a lot of people do want that complexity (disagree with that as you or I might).
As much as I love to hate Atlassian, I feel like complaining about Atlassian is like techies complaining about management in general. Every single anecdote is both terrible and true, but it's not quite as easy as it seems to do it better.
This is the primary failing of many tech people/companies. You can't compete by just building a "better" technical product.
Everything from sales to support to customizations and integrations matter to companies, especially as they grow and develop their own teams and management structures which require the software mold into their workflows. Whether the management processes are the best is a different conversation, but being able to support any scenario is why Jira and Confluence are so successful.
It's the same reason why Salesforce has dominated CRMs even with so many "modern" alternatives around.
Because Jira is flexible and has the needed features and integrates with most things you care about. To the point where everyone in the org can tolerate it. Alternatives tend to focus on one group of users and the rest HATE the product.
I've tried a lot of these products and in the end come back to Jira because it works better on average for everyone.
This comment nails it - anyone who has had to investigate other offerings that satisfy the needs of project management, design, and engineering will quickly find that all the other options out there are total garbage in comparison to Jira, which is why Jira remains at the top of the totem pole for what it does.
As an engineer & former manager, there are definitely things I didn't like about Jira like slowness, but everything else I investigated/used were worse in multiple significant ways.
There's a worse world - one where you have on prem Jira, Monday, Paper, O365, Confluence, Github, and internal api documentation all out of alignment with the other. I'm begging to just end my misery.
The other thing about jira is it’s configurability. I look for replacements every so often and all will require us to change our process. We have adapted jira to our exact process like I’m sure many teams have.
The thing about products that occupy the kind of niche that Jira does is, the people using the product are not the people making the purchasing decision. They rarely even talk to each other.
If you come to a venue like Hacker News, you'll mostly be getting opinions of the people who actually use the product. These opinions do not reflect the interests and priorities of the people who decide which product to buy.
I wish I knew the answer as well. I believe many managers trained in the art of building software without knowing how to build software are too married to doing processes in a very specific way that's very tightly coupled to Jira, and feel safe and at home with the added complexity it provides, so they vouch for it. But that's just a theory from personal experience.
Jira is as complex as you make it and you can't solve people issues with technology. So another solution won't solve your manager problem. That said, the UI is an abomination that will one day summon the elder gods to reap us all.
I mean, if the problem you have is that Jira lets you set up overly complex workflows, then a more limited solution that forces a simpler way of working could have a positive effect? I do agree that you don’t HAVE to make things more complicated than necessary in Jira, but obviously some do that anyway.
If the manager wants a complex workflow then they will make one outside the project management software if needed. Except now you'll need to manually track everything as a developer.
Then they'll just have the same requirements outside the software and it'll be on the developers to manually track it. Then communicate it in hour long standup meetings or something. Or bother engineers every few hours to communicate them directly. Complex corporate processes predate Jira and exist in places where the only tracking is Excel documents.
I used Clubhouse at a past job and it was great. I can understand why companies may not be able to move off of Jira, but I can't understand why one would start using it in today's world.
I think it already has been disrupted but no company is going to switch task management software without a really good reason. But I can't imagine and fresh companies are choosing Jira over Clubhouse, Asana, Trello or what I hope to be my company at some point! https://tahsk.com
Yeah I've heard a lot of people using Gitlab as you don't need to mess around with any integration and it's all in one place which is really nice. I find actually managing the issues super lacking and frustrating personally though.
The thing about Jira is that it provides much more than just tickets. It's really not even bad at what it does as far as user workflows go, it's just really easy to misconfigure due to lackluster administrative tooling.
I work with a Jira instance that has something like 20 years of history and over half a million tickets. Migrating just the tickets and their comments might be possible, but migrating all the other metadata and every service and automation we've integrated into the workflows (some of which we depend on to be able to work at all) would take months of work if a suitable alternative even exists in the first place.
If it were just tickets and some CI integrations, migrating away from Jira would be trivial, but that's not where all the value is.
A far stretch to conclude that this event can equate to awful engineering.
The rest of this your comment reads like you continue to be naive to Atlassian’s success. I have to think many people do find unique value in their products (myself included), some people don’t laugh rudely when they hear what folks are working on, and I think that shows in the overall achievements of the Atlassian team and product.
I’ve witnessed first hand truly fantastic organizational changes after adopting Jira, Confluence, etc., and I wouldn’t continue to write them off so easily.
And I've witnessed first hand the truly garbage nothing changes after adopting Jira and Confluence - a wasteland of process management through bad automation and forgotten wiki articles with Write Once Read Never behavior.
Nothing Atlassian does is that much better than past tooling, it all comes down to how you want to run your org, what discipline you apply, and where you apply it.
One of these things is not like the other, and anybody who uses a real editor and VCS but still has to deal with confluence or the rest of the above knows it.
Child poster below going on about markdown etc is absolutely wrong.
Agreed, it’s a total waste of time, I’d say our managements love for JIRA is the things that’s really holding us back from really being productive and enjoying our work. It’s such a horrible horrible time suck and offers nothing of real value.
>overhearing someone ask a developer, “where do you work?” When the developer responded with “HipChat,” the other person immediately chuckled and said, “oh — Atlassian... I’m sorry” — and then everyone around them also started laughing.
> It’s amazing that this company continues to fall up.
There are still not any knowledge base tools that can keep up with Confluence. For Jira the competition is slowly catching up but there are still a large gap for big organizations. That's why they are still here, their product is still superior to the competition.
Atlassian get a lot of criticism, that's not always justified
I suspect that a lot of Atlassian's criticism is a reflection of their dominant market position. Outside of smartphones and video game consoles, people generally don't spend much time complaining about products they don't use.
For my part, I've spent enough time using both Atlassian products and competitors to find something to hate in all of them. Familiarity breeds contempt.
A former Rally engineer once told me, "Rally did a better job than Atlassian at making engineers think positive thoughts about Jira."
That said, I can't think of a single feature Atlassian released in the past several years that made the experience of using Jira or Confluence substantially better. (I could at least say markdown support if that was ever ported to Jira Data Center.)
The argument for software subscriptions is that it funds continuous improvement, but most of the top complaints from 2011 are just as relevant in 2021.
There's the famous quote by Bjarne Stroustrup, "There are only two kinds of languages: the ones people complain about and the ones nobody uses". I think that holds true for a lot of things.
> That's why they are still here, their product is still superior to the competition.
No. It's because their products are sticky in nature. The tools are used to hold the current state and historic knowledge of the organisation, and even the thought of replacing one of them gives IT manager types the shakes.
Yeah, I think that perception used to be pretty hardcore years ago.
I eventually realised that so many, many companies use this software as a backbone to their company and operations. And for the majority of those, the companies like it. So much so that instead of migrating to a competitor, they move to the new cloud offering.
* Selecting a language on one code block changes the languages for other code blocks on the same page, sometimes. (I've not figured out the exact conditions on this one yet.)
* Whitespace is not preserved / rendered the same as the editor; we have several Confluence pages with YAML where the rendered version won't parse, but it looks fine in the editor.
Dunno about all that but it doesn't support inline code snippets. You've gotta use formatted text, which doesn't look good. Seems like an intern project at best.
Ya gotta use the mark-up text tab to write, and only switch over to the other one ("visual" something?) to check that it looks OK.
Always annoys the heck outta me when I forget to switch back before submitting my comment. It remembers, and gives me the same tab next time I start to comment on any ticket.
If you are serious about the tunnel between the houses can you provide any info or a link for my bubble folder? I’d love to read about that. Googling was not fruitful.
>It’s only a matter of time before this product suite is disrupted, and it might represent one of the most obvious low-hanging opportunities in our entire industry.
That might be the most disconnected-from-reality statement in this entire discussion.
Whatever you think about the quality of Atlassian's products, they are ridiculously entrenched and about as easy to "disrupt" as Microsoft Windows.
On the other hand, cloud-hosted services can have a CVE patched for all users within a matter of hours (or less). Consider the alternative of frantically trying to get in contact with thousands (or tens of thousands) of companies running your on-prem version and urging each one to install your patch.
> It’s amazing that this company continues to fall up, and that the founders have taken on roles as the ruling digital gurus of Australia
It's probably because they primarily target non technical folks. Our IT department has inherited numerous Atlassian products adopted by business units and it takes at least a year or two to unwind them if ever.
In the meantime the just keep cashing those checks.
Maybe the founders could have used some of that time spent planning a tunnel between their side-by-side $100M houses, or engaged in Twitter rants, to actually bother delivering value to customers. It’s only a matter of time before this product suite is disrupted, and it might represent one of the most obvious low-hanging opportunities in our entire industry.
I still remember being in line at a WWDC a few years back, overhearing someone ask a developer, “where do you work?” When the developer responded with “HipChat,” the other person immediately chuckled and said, “oh — Atlassian... I’m sorry” — and then everyone around them also started laughing. It’s amazing that this company continues to fall up, and that the founders have taken on roles as the ruling digital gurus of Australia (shows you why it’s so easy for the government to run circles around the local tech industry and pass whatever laws they want).