Atlassian is 20 years old and unprofitable
smartcompany.com.au
smartcompany.com.au
When I worked there, they disclosed all financials in our internal Confluence site. There was a policy of full transparency with the employees. The owners (Mike and Scott) had impressive business discipline. They were profitable every quarter. They had many many opportunities to get vc money and go wild. When they finally took VC money, It was a modest amount ($60M I think) and the purpose was explained to us as setting up an ESOP program and putting Atlassian on the path to go public.
A year or two later, Doug Berman, the founder of Great Plains software became chairman of the Atlassian board. He gave a presentation to all of the employees at the Sydney office. One thing that stood out was that he said, it's actually bad to be profitable when you're growing. I'm paraphrasing here but he essentially said, you're leaving growth on the table. His thesis was growth is more important than profits.
So whether you agree with that or not, that is obviously the idea they are operating on rather than uncontrolled spending and helicopter dropping stock on employees heads out of desperation.
What you're left is a company with 8000 employees and a system to problematic to change.
With the recession incoming, the time for free money is over and tech startups are bound for a correction. I'd sell or get ready to wait 10-20 years.
Even in the wait scenario, you're basically hoping that a huge corporation will transform itself and rediscover their startup roots - which is not likely to happen.
It happened with Mashape (sold their unprofitable marketplace to the RapidAPI people - geez, what a bad deal, it was painful to watch) and they managed to reinvent themselves with Kong.
They literally did a bunch of experiments and went on with what succeeded, ignoring their main, flawed, business model.
That's what companies should do to chase success, they need to act like venture incubator, don't bother their teams with corporate BS and hope one of their teams will succeed. If they behave like mammoth corporations they're doomed to fail.
https://investors.atlassian.com/news/news-details/2022/Atlas...
And their typical customers are the least exposed to recessions i.e. medium to large companies who are making software purchasing decisions for the long term.
And even if Australia is unaffected by an American recession, much of Europe, and much of Asia won't be (especially with China's growth slowing down).
Which brings me to my second point, which is the only reason Australia was able to avoid a US recession was selling itself to China, something which it is politically unlikely to do so anymore (although I'm not up to date on the new PM's China policy) and anyways, China may not have the capacity or willingness to support Australia anymore.
I doubt miners are big Jira users. US tech companies who are cratering right now though...
I see if few of those end up mines that would be epic for consultants but just another story for miners.
Most other industries you’d probably have the workers unionize or murder the agile coaches, lol.
My wife & I have a couple academic friends and they make 1/4 our income probably, but they are unfireable & they also just took off for another 6 weeks stay in southern Europe at a family home this summer .. so there's that.
Guaranteed income & time flexibility are hard to measure in absolute dollars.
My wife & I are on the other hand on our 5th/6th job in our almost 20 year careers, never having had more than 2.5 weeks off consecutively. The hustle now is maximizing the dollars and building some alternative income streams so we can start to wind down the intensity in maybe 10 years and fully exit workforce in 20 years?
Depends on your definition of value. If a companies max revenue is $X, the farther away from $X they are the more of a return you can hope to get!
Revenue .. well, if you can get huge revenue with huge losses and convincingly demonstrate (mostly by spending) that more losses (= more capital) means more revenue can actually take you a long way. Almost all of the "unicorns" and "decacorns" embraced this model - lose $2-5 per $ of revenue but able to demonstrate almost unlimited market. Most of those companies can never, ever be profitable entities.
“In other words, the market is not a weighing machine, on which the value of each issue is recorded by an exact and impersonal mechanism, in accordance with its specific qualities. Rather should we say that the market is a voting machine, whereon countless individuals register choices which are the product partly of reason and partly of emotion.” -Security Analysis 1934
The slow and steady mentality is fine, but we see over and over that it isn't what the market wants. A private company or a high risk growth company, those are the two options for a software company.
Either that or they'll be taken over. They're revenue now is just a $2bn, so that "grow grow" mindset from 10 years ago did not work out. In theory, a steady CEO could try to steady at that size with a nice margin. But, actually declaring and pursuing that would mean halving the companies market cap to a "normal" P/E of 20-30X.
At that price (say $20bn) one of the big software companies would just buy them... for their own growth targets.
Moderation has no place in the public markets as a software company. It's remarkable how unstable a stable condition is.
For the successful companies that do grow into a dividend company, they often have valuations that far outstrip their eventual settling location at some point in the trajectory.
I understand that being small leaves you vulnerable to the predatory tactics of big players, but I see that as a consequence of lax regulation. There are too many mono/duopolies already, and the bigger they get, the harder it will be to split them apart.
Markets pull towards potential, and the potential of Atlassian is valued higher than it's stable state.
Salesforce vs. Siebel being a great example of exactly that.
While I agree with your statement, I had to look that up because it sounds interesting. In 1999, the year Salesforce was founded, Siebel was the dominant player in the CRM field, holding 45% of the market, so not precisely a small company.
More than a budget war against a deal-with-the-devil startup, what killed Siebel was its inertia. Siebel sold expensive in-your-premises software, while Salesforce sold SAAS, and emphasized a cheaper cloud model. Siebel didn't react until 2003(!), when it released its first cloud version. By tht time, the expertise of cloud solutions of Salesforce made Siebel look like an amateur.
Siebel surpassed 1 billion revenue in 2000, while Salesforce did it until 2009. They had their chance.
I still agree that even if a small company did everything right, another one with more money and no fear of heavy losses would eat their lunch even if their product was inferior.
>In 1999, the year Salesforce was founded, Siebel was the dominant player in the CRM field, holding 45% of the market, so not precisely a small company.
Sure, but CRM was a new market back then (many argue that Siebel invented CRM) and Siebel was roughly equal in revenue scale to Peoplesoft and c. 10% the revenue scale of Microsoft. It would be very hard for anyone to argue that they ran out of space to grow (vs. choosing to slow down growth for profitability, especially in light of the dot-com crash)
>More than a budget war against a deal-with-the-devil startup, what killed Siebel was its inertia. Siebel sold expensive in-your-premises software
One great way to stop being an expensive piece of software and to grow faster is to lower your prices (but then you run the risk of becoming unprofitable).
Also worth noting that in 2000, Siebel spent c. 33% of revenue on Sales and Marketing, while Salesforce chose to spend 500%+ of revenue in the same period.
>while Salesforce sold SAAS, and emphasized a cheaper cloud model. Siebel didn't react until 2003(!), when it released its first cloud version.
Again, Seibel chose to spend 13% of revenue on product development in 2000. Easy to crush competition, but only if you're willing to spend for it.
>Siebel surpassed 1 billion revenue in 2000, while Salesforce did it until 2009. They had their chance.
Exactly, and choosing to harvest profit out of that $1bn of revenue too early is what did them in (though arguably, they are still probably something like $1-2bn of market cap for Oracle).
Seibel is and always will be the perfect example of disruption/the innovator's dilemma, which ultimately boils down to 'if you're comfortable with your current profits and not worried about growing top-line revenue, you will likely lose both.'
This, I think, is the core of why. It's not that being a medium sized publicly traded company is immoral or unprofitable - it's that in a public market your stock is priced on future earnings and choosing to be smaller than possible means your tech can be bought for cheap. If you choose to stay smaller than maybe you could be - you're leaving ROI on the table in a lot of peoples' eyes (even if you're right and you'd lose money trying to get huge). So, as your stock price drops off to reflect the expectation that you're not going to get super impressive earning growth, you start to look appealing as an alternative to developing technology for an industry giant. Why spend $5bn over 10 years to develop competing services when you can borrow $5bn today, buy atlassian, get a tax break on the debt and start making a play for market dominance with the atlassian tech?
If you want a small or medium company, staying private is a more sustainable approach.
Except the government got addicted to printing money and throwing it around to boost GDP (and taxes) through bullshit business models and bullshit investments. They literally created framework where being an overstaffed money-bleeding behemoth creates higher returns for the shareholders than being a lean-and-mean niche business.
If you don't go the unsustainable blitzscaling route you'll be outcompeted by those who do, just as Atlassian did to plenty of smaller, more sustainable competitors.
> I understand that being small leaves you vulnerable to the predatory tactics of big players, but I see that as a consequence of lax regulation.
That's nice, but that doesn't make it go away. Do you have a plan to make the regulation non-lax?
1. Companies provide useful products to customers.
2. Growth means that you built products that more customers paid more money for, because it was useful.
3. Thus, growth means your company contributed more to human prosperity.
"only" $2bn ? this is bizarre to see discussed without question
What the market wants is short term growth and I firmly believe that is what is destroying our economy and the market.
Instead of building pillars and companies that outlive the founders, we have short term cash grabs. We have VC firms buying up our existing pillars, gutting them of any valuable assets, saddling them with debt, and then selling off the carcass. We have firms buying up real estate and creating or exacerbating scarcity to drive up demand and prices. We have shifts towards subscriptions and quarterly profits.
It's not healthy and it's destroying us.
Agreed, and its now a pox on the overall system.
What kind of a 100 year future does Atlassian have? Jira certainly isn't a 100 year product. Software is so fast... IDK. The pox is not just a product of greed and malice and nothing.
We're talking about a company that produces products that are widely used. JIRA is not the issue, but the company that produced it. 100 years is stretching it, but I would believe that Atlassian outlasts yahoo.
And has been growing 30% YoY for the last 3~4 years alone. This is unheard of in any other industry/market.
Their FCF is also impressive.
20-30% doesn't get you to a justification for Atlassian's peak value. It doesn't inspire "the next Microsoft" vibes.
Maybe after 10-15 years of growth at this rate, it would... but the market's not paying these prices for that.
Atlassian becomes an acquisition target if stock prices reflect a 20% rate of growth.
It has been common for the leaders in every other market throughout commercial history, as it pertains to corporations of large size. What you're looking at are presently old industries and comparing them to newer, that's where your mistake rests.
Walmart did it. Sears did it. Kmart did it. Best Buy did it. US Steel and its components did it. The various automobile majors did it. Standard Oil and the other oil majors did it. General Electric did it. Caterpillar did it. Pan Am did it. Many of the railroad companies did it during their time. McDonald's, Starbucks and most large chains do it during their expansion->saturation phase. Coca Cola did it.
It's exceedingly rare to find a large corporation that didn't bang out 30% growth years for a decade or more to get as big as they got.
One day, decades from now, "cloud" will look like a big dead industry too, and people will talk about how it never grows fast. Just ask the people that used to make business software you install onto PCs.
Facebook took 17 years and Walmart took 25 years to reach $85B in sales.
Most tech companies have ~80% gross margins. Walmarts is ~25%.
You simply cannot compare the two.
Growing revenue while still not making a profit is not impressive. If you give me $100 today I can go out a buy $100 a pair of new shoes, and sell it for $70. Give me $200 and I'll go out and by two pairs of shoes and sell them for both $84 (total)! Keep giving me money and you'll continue to see this growth I promise!
> This is unheard of in any other industry/market
Given my example above, that should be a warning, not a sign of success.
I find it mind-boggling that people can really not even grasp that growing revenue with out demonstrating you can transform that revenue into profit doesn't mean all the much.
Grow profits every year by 30% and I'll be impressed.
It is when you’re a software company and the marginal cost of the goods is zero.
$600mm annual sales and marketing isn't cost of goods but the method of accounting that I subscribe to includes such costs as a fundamental cost of production delivery.
Subscription revenue isn't the same as revenue in other businesses.
Hilarious that you use the analogy of shoes. This is exactly the problem. Great explanation on this concept:
https://a16z.com/2015/05/15/a16z-podcast-why-saas-revenue-is...
> Grow profits every year by 30% and I'll be impressed.
Oh, you mean like Facebook did?
https://www.statista.com/statistics/277229/facebooks-annual-...
This phenomenon might to some degree be a function of the board’s veto power over the CEO. A primary reason you typically go public is to grow, so by default at IPO you’re a “growth stock”. But from that point on, its difficult to ever make a transition to a steady, sustainable “dividend stock”, especially as a tech company. If you try to, the stock will tank, all the “growth” investors will get mad and you (the CEO) will probably get fired by the board, and they’ll bring in a new “growth” CEO.
How does it NOT make sense? The purpose of a business like this is not to generate some short term profit. These are winner-take-all markets - they're playing for complete and utter domination of an entire product category.
Their Q1 revenue grew 37% YoY - how on earth would you care about profit over what they doing here? They should keep hitting that as hard as they can.
Teslas are profitable, once you pay off the amortized cost of a factory. It isn't clear that uber is profitable. They had 5-10% gross margins pre-IPO, and it has gone negative since.
It is not necessarily true for other sectors (e-scooters, different delivery services, maybe even Uber), as there is no stickiness in those areas. Whenever a cheaper Uber would come to my city, I'd drop them within a second. They are usually cheap while they can burn VC money.
If Atlassian can keep their system for a couple of years in a big, slow legacy company, the company will end up with tens of thousands of tickets and pages.
Then, no matter how everyone thinks that all the products of Atlassian is terrible (there is a thread about it every second month here), the company will never leave Atlassian because nobody wants to spend the time on migrating all that stuff and everybody is afraid to say that "we will probably not going to need poorly written user stories from three years ago", and they don't want to risk that the new system doesn't cover everything that e.g Jira does.
Once a company is locked in, it will keep paying because paying any amount is easier for them then migrating, training the employees to use the new system, broken links, missing features, etc.
Isn't the stickiness that drivers will only switch if customers use it, and customers will only switch if drivers use it?
Consumers switch because prices are low since the rideshare company is artificially subsidized.
Atlassian is well-managed. Their revenue is fine. Their cash flow management is good. Their compensation plan is effective at retaining employees--the stock employees receive is likely to be more valuable at the end dof the vesting cycle than it is today.
Atlassian has got a collection of offerings that are industry standard. When used at large companies, they become quickly entrenched, with very low churn.
It is also a collection of offerings that is chosen by startups. Last quarter through a year from now, I expect that stream to be dry. But they are on 3-year contracts at an awful lot of got-my-Series A startups that will have to tighten their belts in other ways before trying to rotate off of Atlassian.
But, you can't grow forever. At some point you hit things like the maximum market size and there's no longer any way to invest your profits back into growth.
Or, to hit a lot closer to home: As a stockholder, your stock won't appreciate in value forever. Software companies very rarely turn into Microsofts and Googles. You need to sell at some point in order to realize the value of your investment. (Unless you're getting dividends.)
Atlassian is probably a fair bit away from that. Amazon is much closer to that mark today but they got there after following exactly this strategy since the 90s.
How do you justify that?
One way Atlassian's market size gets limited is by being viewed as a competitor to Microsoft (or other large incumbent's) products. Some customers can choose both, but not everyone can. The feature and experience differences don't matter much to the buyers (procurement), so if something is cheaper elsewhere, then it's a harder sell. It also increases risk in a potential recession where Atlassian is viewed as a luxury option. I feel like JetBrains play a smarter game here.
It feels like folks have forgotten how bad a niche developer tools have been. Circumstances have meant that VCs have been throwing money at developer tools and developer experience has been in vogue. Things will probably be better in this wave than previous ones, but it's still much riskier than other markets. Developers may rule the world, but the software powering their day-to-day is very different between software companies and the majority building line-of-business software.
I don't think people, even here, understand how simply large and growing the market is for software development tools.
https://www.gartner.com/en/newsroom/press-releases/2022-04-0...
If that means profits available to, e.g. pay dividends with then sure. But I think it ought to always be the goal to have a profitable operation then you can plough the profits back into the business to push growth (which will mean reporting 0 profits).
I worked at Rising Sun Pictures (RSP) in SA 2005–2007 and the CEO at the time, Didier Elzinga, did the same.
But what RSP did went even further. Didier and the CFO did a full disclosure presentation about the company's financials quarterly or bi-annually (can't remember).
It was great. Not least to make everyone understand why they couldn't pay rates that VFX professionals who moved to AUS from the East coast or London where used to – at least at that time (it was early years for RSP then).
RSP remains one of the best workplaces I ever had the luck to be employed at.
Afair Didier was also in some role on the board of Atlassian at the time. Maybe not a coincidence.
Seriously, when did it become normal in capitalism that you should not prove that your business can make money? That there a customers willing to pay for your product? That the promise of future maybe profit sells better than actual profit now? This is insane.
There's a difference between 'not profitable' and 'losing money.'
The issue is that many of these companies have never demonstrated that if they want to they can be profitable. The big assumption in these growth models is that there is a point where you can just magically flip that profit switch.
For example if I run a lemonade stand where I spend $3 to make a $1 glass of lemonade, even if I am able to use investor capital to keep growing my lemonade stand to be the only lemonade stand in town, or even the world, it's not clear that I can survive if I'm forced to make a profit.
This has been the consequence of increasingly cheap money and investor money having nowhere to go after the real estate crash in 2008. To be fair, if money is basically free then it does make sense to grow without worrying about a profit. If you've had an entire career without every having to worry about more investor money coming it, it would start to seem wasteful to not spend it all.
But that's why these current economic conditions have me very worried: money can't be cheap anymore. If interest rates continue to rise we'll see a massive contraction in tech. First it will be the smaller, direct to consumer startups, then it will be all of the companies that have those startups as a non-trivial portion of their revenue.
I've seen this happen so many times:
- profitable, down to earth founders generating net profits
- VC approaches said outfit and tries to gather as much info
- VC realizes said outfit is difficult to emulate and break into market
- VC invests and starts demanding they run at a loss to grow quickly
This works well when interest rates are low, and VC is not under pressure to deliver returns. However, when capital suddenly becomes slightly expensive, the whole house of cards start to crumble taking down the good business with it.
Neither strong prudence or optimism helps here. Once you start running at a loss post-VC money, you no longer control the destiny of your own company you started.
Let this cyclical downturn (likely to last for 5 or more years) be a lesson that the previous generation learned. If you are not making growing net profit (Revenue - COGS), you are no making period. Not so while ago people were arguing that debt is an asset and cash is a liability. It's always amusing to me how quickly people denounce gravity are impacted by it.
The good times are over for VC backed SaaS
- Your entire theory relies on VCs having some power over decisions being made at Atlassian. That isn't the case. The founders of Atlassian have always been in control. After taking VC money and going public, they still have over 80% of the voting shares [0].
- A downturn of 5+ years would be the longest downturn in the USA in the last 100 years [1]. Anything is possible but it's unlikely to be that bad.
[0] https://www.businesswire.com/news/home/20220527005335/en/Atl...
[1] https://en.wikipedia.org/wiki/List_of_recessions_in_the_Unit...
GDP contraction won't last five years. But it will be longer than the GDP contraction before VC money becomes as easy as it was for the last five years.
A founder isn't forced to take on investors. The same founders who were so "down to earth" and profitable are the ones making the decision to take on investors. The founders can't be responsible for profits and then suddenly get taken advantage of by investors. Everyone involved is eyes-wide-open.
Lots of great businesses have been built, in partnership with investors, during higher interest rate periods and downturns.
And maybe there is no good option, no matter how “down-to-earth” they are.
Disagree. These companies absolutely pump out cash on a free cash flow basis:
"It’s the absolute dollar free cash flow per share that you want to maximize, and if you can do that by lowering margins, we would do that. So if you could take the free cash flow, that’s something that investors can spend. Investors can’t spend percentage margins.” “What matters always is dollar margins: the actual dollar amount. Companies are valued not on their percentage margins, but on how many dollars they actually make, and a multiple of that.” “When forced to choose between optimizing the appearance of our GAAP accounting and maximizing the present value of future cash flows, we’ll take the cash flows.”"
https://25iq.com/2014/04/26/a-dozen-things-i-have-learned-fr...
I believe that's Doug Burgum (now governor of North Dakota).
VCs love risk. They will want to dramatically reduce your chances of a small positive outcome if it means a increase on your (always small) chances of a huge positive outcome.
Anyway, that can quite possibly be perfectly aligned with your company's goals. It's not a bad or good thing. It's just a thing.
Business risk stuff - does the market exist? is a new pricing model possible? etc. - is not at all on the list of risks that VCs like.
The only conclusion to this statement is "When we will stagnate we will then start making profits"
This doesn't sound like a great strategy to me. This is why I'm not investing in "no-profit but growth" except for the stock price increasing in the short term.
A few days ago[0] I was writing a Jira ticket after hitting the "Create" button and I wrote the description (the body of the ticket) for ~30 minutes. I switched the ticket type from A to B (no epics involved) and it wiped out the entire description. All I did was select a different item in a select drop down box provided by the form's UI.
There was no warning it would clear the description and no draft saved. I lost 30 minutes of work.
I normally manually copy textareas every few minutes on any Atlassian page because I don't trust their site (to be fair I do this for most sites too) but in the above case I had just copied a link reference which overwrote my clipboard. At the time I also didn't have a multi-clipboard tool installed since it was using a company issued machine that I don't have tricked out yet.
[0]: https://twitter.com/nickjanetakis/status/1540353527859466246
Jira does this better, but is still weird with their text formatting. There are two different kinds of input fields, one of them accepts markdown, the other one some other kind of markup language. Copying some formatted text from one of the inputs to the other doesn't work because of this.
If you are in the new editor for Confluence Cloud (i.e. the editor based on ProseMirror rather than TinyMCE), you can sometimes get it to do "the right thing" of converting pasted markdown to formatted text by copying from a different text editor. For example, for me copying from windows notepad always does the right thing, but copying from vscode doesn't.
Make one mistake, you're good. Make two, tough luck, you can only undo once. Accidentally select some (or all) text and type over it then somewhere else? Today's really not your day. It's actually worse than textboxes in this respect.
This happened to me more times than I'd like to admit before I knew better.
It's actually one of the best on Windows, because if you leave your computer for a moment and it randomly decides to restart to install a Windows Update, often a notepad with unsaved changes will block it from restarting, whilst unsaved work elsewhere won't.
saved my sanity more than once regarding lost jira inputs
That "Issue Type" dropdown box is what I changed a value for and it cleared the description below it (also seen in the screenshot).
Our set up might be pretty basic because the A to B from my original comment was "New Feature" to "Improvement" which is included in that screenshot.
Every issue type is configured with its associated issue-create screen and that screen has its fields. When you change the issue type during issue creation you're replacing one set of fields with another which results in the information loss you experienced. This just doesn't affect the description field, but all other system fields and custom fields.
As far as confluence, or just about every web tool I've used that has text areas (slack, etc) - I really wish that would be handled over to the browser.
This leaves them very vulnerable to another company taking their market share, as soon as they create something better that is extensible enough to get management signoff. I know a lot of companies have tried and failed here, but someone's going to eventually do it.
What are the equivalents for Jira ?
Is there an openish source piece of similar software ?
Jira cops a lot of hate on HN, but really to paraphrase Churchill on Democracy - "Jira is the worst issue tracking software, except for all the others".
The comparison on Wikipedia has so many of them : https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_s...
Are any of them any better?
But the tool felt fairly fast and did it's core job pretty well.
In many ways it's like Excel. Everyone says making an Excel killer should be easy because people only use 10 features. Problem is, everyone is using a different 10 features.
The only thing I see in Jira as an actual gap is the inexplicable lack of a standard view for showing all of the tickets in a particular sprint. You can make custom queries, of course, but it’s such a common need which everyone else on the market solved in 1.0.
The problem with Jira is the total disregard for UX. Very simple tasks like moving tickets out of a story take way too many steps when it should take one click.
They don't seem to want to improve it because of legacy customer or reasons....
If the issue in your company is tracking software, your company is probably full of anal PMs and a nightmare to work in.
We used to use zenhub, nowadays we use github projects
Something that gets "close enough", like Mattermost/Rocket.Chat can get to Slack? Probably nothing, given how huge the surface attempt for Jira is.
But for project management and issue tracking in general, there are quite a few alternatives:
- OpenProject: https://www.openproject.org/ mentioning this first, because it's what I use for my personal needs and feels pretty decent (issue tracking, time tracking, references, comments, files, Wiki, cost reports and so on), though is definitely not nearly as popular
- Redmine: https://www.redmine.org/ is probably also a really good alternative to mention, while the original UI is dated a while ago there was a project to create something more modern and most of the times when someone is using an alternative to Jira, I've seen it be Redmine in particular
- Odoo: https://www.odoo.com/ is a more modular system that I haven't really used much personally, but have heard about being talked at the occasional conference in my country, the idea seems nice at least
- Nextcloud: also has some apps, like https://apps.nextcloud.com/apps/tasks and https://apps.nextcloud.com/apps/deck that, while basic, can be really easy to get started with if you already have Nextcloud
- Kanboard: https://kanboard.org/ is perhaps the best Kanban board that I have personally used, just because of how snappy and lightweight it is (at the expense of the features it has, admittedly)
Oh, I also probably should mention GitLab, which has lots of project management features built right into it nowadays, as well as stuff as release management and whatnot: https://about.gitlab.com/features/?stage=plan
One equivalent that does everything and is as flexible as jira, I don't know.
There are however a multitude of software that provide some of the functionnalites or can do many things jira does but in a more opinionated way.
It depends if one's company want a tool flexible enough to suit gazillons of different workflows with integration with many other tools or not. If the goal is only to have tickets and kanban boards I think there are many alternatives.
One equivalent that does everything and is as flexible as jira, I don't know.
There are however a multitude of software that provide some of the functionnalites or can do many things jira does but in a more opinionated way.
It depends if one's company want a tool flexible enough to suit gazillons of different workflows with integration with many other tools or not. If the goal is only to have issues and kanban boards I think there are many alternatives.
Funny thing is jira is such a mess Atlassian introduced jira service desk more focused on tickets while the former can also do that.
Not quite. Service Desk (aka Service Management today) has a number of capabilities that differ quite significantly from Jira Software. The most obvious is the end-user facing help portal. But how users are managed is quite different, it has SLAs, different reporting, a knowledge base, etc. Just like Jira Software is flexible but tailored to software teams with boards, backlogs and sprints, Jira Service Management is tailored to IT teams and requirements specific to that market.
I use Linear these days, and that's great too. But for a small company? I'd recommend Redmine.
I started using Linear recently and I can never go back to Jira. Linear is that good.
My personal preference is ClickUp or Asana as they offer flexibility to bolt on routine task management in a much more flexible way.
(This is the same failure mode as many Agile-as-practiced projects have: once the incentive structure is decoupled from results, someone will have a full time job moving tickets around in a way which is considered productive even if the project is foundering.)
It’s almost as if the PM is the problem instead of the solution.
I also wouldn’t be so quick to condemn the PM. I’ve seen plenty of developers insist on complex workflows and custom fields because they think they can automate everything, only later to realize they’ve created a second job. The problem is basically the lack of a functioning feedback mechanism to ask “do we need this enough to pay for its care and feeding?”, and I’ve seen people from every role on either side of that, although it’s certainly more common to see business people underestimate the complexity of what they’re asking for.
I think this is a factor of their days being filled with busywork (from my perspective), so naturally the dev should have time enough to do all that during the day as well. The people asking you to fill out all those fields are not the ones actually doing so (or their entire job is filling them out).
The Atlassian terms of service make it illegal to discuss Jira’s speed.
I refuse to work on any project using Jira. It’s the first question I ask in interviews.
I've also used Redmine a few years ago. It gets the job done but nowhere near as slick and fun to use.
In practice scrum is extremely unagile, because there is one very particular workflow to be used and actual workflows have to be adapted to suit scrum. Sometimes it leads to increased agility, but more often than not it does not.
Probably the central piece of scrum are sprints. Nothing wrong with sprints in general, but sprints rely on feature sizes being sprint-sized. Sprints only work when you actually finish planned stuff over the course of a sprint. Naturally, feature and especially release sizes vary. By focusing on milestones one can actually plan and schedule work and releases. This is agile - you can shuffle stuff around. Instead scrum tries to sell fixed size sprints to give impression of steady movement forward, but this decouples sprints from milestones and slightly counter-intuitively reduces agility - shuffling milestones around sprints merely gives you a bunch of unfinished milestones, but also a bunch of finished sprints. But variable sized sprints based on milestones sound too much waterfall-y when the selling point is departure from waterfall.
Interestingly this attempt to squeeze features into sprint-sized chunks is one of the reasons for technical debt that you then must somehow manage, simply because squeezing features comes at a cost of technical debt. There are more reasons for technical debt, but it is slightly humorous when a tool aimed at managing/reducing technical debt introduces debts of its own.
A bit tangential to scrum, but Facebook's story of Hack/HHVM is well-known story somewhat indicative of this. When you size features according to wall-clock sized release cadence (instead of sizing release cadence according to feature sizes) you inevitably accumulate technical debt - new features should build on top of past features, but deficiencies in past features prevent new features from being built on. There are more or less 3 ways this plays out: 1. actual feature release cadence drops due to increased development weight; 2. release cadence drops due to fixup "features" being released; 3. release cadence drops due to dedicated to fixing. Do not get me wrong, technical debt accumulates and impacts release cadence any way, but with feature sized sprints this does not come out of nowhere.
Over the years teams (usually informally) understood deficiencies of scrum process and started throwing pieces of the process away, shuffling them around and having weird mess of system. This is not due to scrum not being well defined, but rather scrum being a hammer in search of nails.
Agile methodologies generally came out of manufacturing - process based workflow. Scrum takes those practices and packages them as a project management tooling. The whole point of agility in processes is the ability to adapt in the middle of the process. Project management, on the other hand, needs plannability and progress tracking. There are weird intersections between the two and IMO scrum fails to satisfy both - neither it is good at adapting mid cycle (because scrum checkpoints mid-feature), nor is it good at future plannability (because it focuses on short term goals). I have seen scrum get distorted in two major ways: either "sprints" get stretched into months long waterfalls, or sprints mostly reshuffling priorities in "in progress" pile and checkpointing progress.
Then cite the definition? If you will cite the https://scrumguides.org/ - I have yet to work in any team that uses scrum that follows this even slightly.
Not in my experience, at least not enough of an impact to make me really care. Azure DevOps was far worse in my experience, and many of the ones SW Devs promote can't roll up to the portfolio level which is where the strategic and purchasing decisions are made.
Their intentionally obtuse marketing all over NYC would drive me insane. Then one day I had a natural reason to stumble upon it, it was had literally nothing to do with what the advertising implied, and the interface was so deeply overwhelming that I wouldn't wish it on my worst enemy.
Like an almost anxiety inducing level of overload from the moment I tried to use it.
Maybe it's great if you live in GANTT Chart Burndown Land, but generally you want something that everyone can use, not just your PMs.
I had a look at Asana again for non-software project management after dismissing it 8 years ago when trying to use it, and was pleasantly surprised: it's much more opinionated than it used to be, a lot slicker, and it integrates with everything I use.
I also use Linear for software development, and won't ever look back.
Gitlab & Github issues is also pretty solid. Lightweight, but it works for what it does.
Asana is another decent competitor, though I don't tend to recommend them for project management. Its there though.
I've organized some small software teams using Notion. Its surprisingly functional. The big downside is the lack of universal structure or a decent API to even build your own analytics against; great for the ICs, but not great for managers.
Best software UX is made by smaller teams that dedicate themselves to solving one problem for a very specific niche. And once they grow, it all inevitably turns to sh*t. C'est la vie..
Atlassian has massive network in its ecosystem. There are Jira Consultancies, 3rd party apps and plugins and deep integration into customers processes. If one element grows the whole ecosystem profits.
Secondly, Atlassian is not a bad company just because it's stock is overpriced. It might be a bad investment!
Over the short and midterm Atlassian is in some trouble because it has problems to scale the development while shifting from legacy to cloud. They will solve it. Still i expect some bad news to come.
These bad news will beat down the stock and maybe create an opportunity to buy a great company at a great price.
PS: The Atlassian invoice of my employer tripled over 1 year. You start cheap and simple and with every plugin and product you add the invoice grows. Thus to value Atlassian you have to look into revenue per customer over its life time, which is far greater than this year's revenue of the customer.
Network effects are where the direct value of a product grows simply because the number of users increases, causing the network itself to grow. The classic example are social networks. The more people on your social network, the more people are likely to join your network and less likely to join a smaller competitor. I am not sure there is anything in Atlassian’s product offering that quite fits that description, but that isn’t to say there isn’t plenty of upsell and cross sell opportunity as you describe.
Ecosystem is the better word for sure. it's competitive advantage is still a network effect.
That’s the network effect
That said, 99% of software projects I have been on could be managed with a simple Kanban board like Trello (which they now own).
Unless your firm has staff who are full time Jira jockeys in the form of project managers, you'll never be able to leverage the more complicated workflows/linkages/planning features.
Obviously a bonkers idea, but they went for it. It was just jira all the way down. They wanted us to create separate tracking jiras for pages, before we worked the issue in the middle of the night. Nobody was actually doing anything, especially the devs I lasted a couple months before I moved. At the end of the year, everyone that stayed got promoted a level as a dev. I went back though git and couldn't find a single commit from any of them. Just bananas, they all got promoted to a higher level as devs for busy work, but jiras don't lie, right?
Despite this, exactly zero shops I have worked do management believe their managers will understand those views.
Therefore at a weekly/monthly/quarterly cadence, "someone" (dev leads) have to spend hours hand updating some horrific excel view of project statuses for big management to understand.
And yet when you ask if we can change from JIRA to something else they say "but my reporting".
Twice now I've worked at places that used Jira, and all it takes is one corner of the company to leverage it for some random oddball purpose to make it painfully slow.
One place started using it for managing thousands of assets, and eventually they were paying contractors tens of thousands to optimize their JIRA instance and untangle the mess.
Same thing is happening at my current company, where even in the last few months it's gotten painfully slower.
You're spot on about that. I've been the "someone" dev lead doing this so often I decided that someone should build a system that does this. You can see my progress so far at fixed.pm
If you are a PM and you come on a team that isn't using JIRA, and you want JIRA with all it's fancy bells and whistles, that's fine. Set up a board yourself, write all the tickets, capture all the work that's happening based on the dev's tool they are currently using, and update all the knobs and buttons to your heart's content.
My guess is the infatuation with JIRA would quickly diminish if this was so.
JIRA is the case of a product made for buyers/deciders rather than for final users, like the dreaded enterprise ERP.
Atlassian's Product Managers believe their product is mostly used by other product managers, but they're dead wrong. Not that it matters, anyway. Atlassian could probably fire all PMs tomorrow and it would be the same, as long as the software ticks all the necessary boxes it will still sell the same. Just hire more marketing, sales and evangelists.
No two firms, and often within a firm.. no two teams has a similar definition / system in how they are used.
My last manager it was like a sniff test / definition of art thing. Constant arguments about epics being too granular or not granular enough. Bumping tickets up or down the hierarchy was hell and lead to many many hours of wasted efforts.
Other solutions might be better than JIRA in A, but absolutely suck in B. JIRA is “sort of shitty” in everything, but the worst in nothing.
I mean:
- Actually caring about the difference between task and user story
- Meaningful / accurate card descriptions
- Keeping information up-to-date on TODO lists and comments
- Projects and milestones that make sense
- Task status and workflows that make sense (besides TODO/DOING/DONE)
Nowadays, I would rather have project management software with the minimal amount features that can't be misused.
I find that a funny description because I've worked with many many different full time project managers who always took the view that putting data in Jira or equivalents and pulling reports before the project meetings were entirely a technician's job.
What is the value add of an engineer doing project management work in an environment where project managers exist
Should the project managers need to do a little coding then?
Also the quiet part out loud - project managers tend to be vastly cheaper (often 2:1) than engineers. Any and every task that an engineering team can offload to a project manager is big dollars saved by the firm.
I frequently find myself in engineering roles where I am doing most stakeholder comms, requirements gathering, JIRA ticket entry/management, project planning, user documentation, support runbooks, PR reviewing, a bit of dev, occasionally testing, deployments, and sit on the support escalation pager rotation. Any of the above tasks you can offload to a non-engineer saves the firm money.
1. Often the way companies are structured requires specific teams and processes to exist and unwinding that is not easy.
2. It can be very hard to identify which people are actually critical. If you get it wrong it’s a big problem.
3. Additionally, firing a large percentage of employees will create a very negative feeling in the remainder so they might leave as well or their work quality will suffer.
4. Customers may lose faith in the business as a result and switch. Something like Atlassian has many competitors.
Are there any specific examples of this being done successfully?
The trick for this being successful is most of the time by challenging the processes themselves, rather than the employees. Employees aren't useless, but process are. The reason you need 500 people rather than 250 or 100 or 50 to do something might be simply because you said so somewhere or sometime.
So, companies should review and change processes BEFORE reducing headcount. But alas, companies don't ever do it, because it requires introspection, egolessness and actual work, the sorta stuff that is rare in upper management.
It also may reduce the need for middle and upper management.
In fact, if you give people some confidence that they won't be fire and instead you will use their work on some more valuable action, ICs will line up on your door with ideas on how to cut their processes. But management won't.
Amusingly, the best "firing" in one of those was the Dean of the University that had a seven-figure salary. The board replaced him with an administrator and with someone else from the faculty, and both were more qualified, but costed 1/10 of the price (still a huge raise for them).
They where profitable, they didn’t need funding the only funding they took was for staff to sell some of the equity.
Them now making a loss I think is more a deliberate choice, not a business failure. They could of continued as they where making $$$ but instead choose to go from 700 people at ipo to near 7k today for pretty much the same product suite.
Those 7k people have to be working on a lot of stuff behind the scenes, building on existing products and maybe yet to be released products. Atlassian always said they where big on long term investment. I’m sure they could be profitable if they wanted but then would need to massively cut the long term investment.
I’m not to worried about Atlassian. Every large org I worked at is run off Jira. I do regret not selling a small parcel of TEAM at the end of last year though when it was over $440usd a share
But this is exactly the kind of thing that makes a market analyst yell "FIRE!" during a bear market. Nobody trading stocks is going to look at a 10x headcount increase without meaningful additions to the product offering as a good thing.
Revenue in 2015 was $320M, In 2021 it was $2B. That kind of growth requires growth in Supporting functions and infrastructure teams, not just in product.
Lol. At some companies, Jira workflows literally run the whole company. At my prev job, prod deployments were tightly linked to Jira.
that's doing a lot of work in that sentence!
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)
Migrating out of JIRA is analogous to "trying to remove an invasive cancer".
Asana is great for SMBs but for larger developer teams it lacks a lot of features and integrations.
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).
It always seems hard enough to get information out of JIRA using JIRA when I watch our PO in planning meetings.
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.
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.
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.
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.
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.
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.
Each team can have a different workflow with Jira
Jira works for non-software-development tasks as well
I've seen it used on companies having 4/5 levels of stories deep (think Initiatives/Epic/Stories/Subtasks/etc. Different companies split this different ways.
The plugins sound inconsequential but they are very useful (almost a must) in several occasions.
Is there a breakout of company size vs revenue for Jira? Because for the past 10 years I've worked only on smaller companies and they all, no exceptions, used Jira as well.
Most complaints I’ve heard about Jira boil down to the horrible processes people choose to implement in it.
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.
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?
The author points at monday.com: I used it a few years ago and it only has basic and useless integrations out of the box, even for a service like Gitlab. You either develop what you need youreslf of try to so something with Zapier.
ISO (the standards body) has started using it, I'm sure in part because large companies who contribute to standards were already using it. The committee that I am a member of switched from Bugzilla to it.
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.
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
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”?
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.
How out of touch can you be with the stickiness of enterprise SaaS, and still write financial commentary?
Here people talk a lot about creating a good product, code quality, etc. It doesn't matter. You don't need to build a great product: you need to find the market and exploit it faster than you can. The quality of your product is not important.
How is Atlassian with so many bad products is valued at $52 billion? Jira is one of the worst products in the eyes of developers. But it does not matter. Managers love Jira because with Jira it's "very easy" to create a workflow and micromanage everything. And managers decide what's good for the company, they have the power to buy Jira.
But Jira is not Vilain. The villain is the school of management through fear, micromanagement, etc. I worked at a company that created an internal JIRA. It's worse than Jira. It was too complex to fill everything, we create a script to do this.
> Here people talk a lot about creating a good product, code quality, etc. It doesn't matter. You don't need to build a great product
You really haven't disproven that CTOs and CPOS loved the product initially, which I believe to be true.
So yes, you do need to build a great product at the beginning. Then at enough scale, your product can become shit in some ways, and you can focus on sales.
But the article's thesis is that Jira did not start as a shit product.
As an example of a tool that found a market in the area of developers is Docker. I used docker in some companies and my God, Docker is buggy as hell, sometimes I pull new code in git and Docker doesn't see it, I have a lot of network problems, etc. And have no idea what Docker was like in the beginning, but when I used it, it was horrible experience, and developers continue to use it. I'm very happy that my current employee does not use Docker.
That's just plain nonsense.
I dislike using Jira as much as anyone, mainly because it's so excruciatingly slow.
But there is no competing product (suite) that offers comparable functionality and provides the same long-term flexibilty. Many companies have built entire workflows (not just development related) around Jira, and have huge knowledge bases in Confluence. Switching would come with a lot of effort.
I will say that most of the Atlassian products are ... not great.
Bitbucket has completely stagnated and is way worse than Github and Gitlab. They actually had an opportunity there. Once upon a time Bitbucket was the only site to offer free private repos, and it attracted a decent number of users to also publish open source there. A good amount of companies adopted it. But they let it linger and didn't keep up with Github or even Gitlab. Just like Jira it's also slow and awkward to use. (never do large PRs ...).
I see a lot of companies switching away from Bitbucket now because developers are not happy with it.
Bamboo ... meh
Opsgenie ... meh
Confluence is actually fine. If only it had better search and wasn't so slow...
And Jira is so complex, improving it is probably extremely cumbersome because so many features have to be considered and everything has to keep working.
It might be advisable for Atlassian to start fresh with a new ticketing system.
Anyway, they have 8000 employees... they can always drastically downsize and refocus, the company will be around for a while.
And mercurial too. I do miss mercurial.
That, kind of like Mozilla started fresh with Firefox, would indeed be a killer move (edit: provided they _can_ structurally do so).
They bought Trello for that
One problem is, that not everyone is willing to educate themselves and people expect to be able to use things immediately. This causes the push to dumb down things into a limiting experience. If I were surrounded by only technical people, then a plaintext file like an org-mode file with predefined todo-labels, commited to a git repo would beat all of the Jiras, Trellos or whatever out there and it would cost not a cent and be safer to work with, as everything is stored in git.
It still doesn't have native Markdown editing, does it? Major issue IMO.
It has been years, since I wrote in their little feedback box, that it sucks and does not properly support Markdown. They do not give a damn and they are not going to fix their issues. Best to look elsewhere for an acceptable wiki experience.
So it ain't nonsense, users do switch.
I believe that TFS product evolved to Azure DevOps now.
But not everyone needs 'comparable' functionality - an awful lot of people use just some features and not others - because of the awful UI and terrible user experience, these people are ripe to be picked off by a competitor (existing or future). I agree, if a mega-corp is completely in bed with JIRA, its harder to switch, but for a company not making any money (Atlassian), having their small and medium sized customers peeled off bit-by-bit for better products is going to hurt.
Simply put, Atlassian sucks at building products because their culture is not good. They got lucky they had the right idea when they were young and didn't have competition.
Nowadays there are just better products out there.
And while Jira is clunky, but other enterprise grade solution I've used are worse
Don't get me wrong I'd pick lean alternatives any day of the week, but for what it does there's few replacements
Exactly. Other products comes with opinionated workflow or are much easier (and simpler) to use. Once you setup Jira way you wanted (good luck with that) and able to maintain this setup for all of your projects you're stuck with Jira forever - you won't be able to export all of your content to another software. The whole process takes ages and its a nightmare of going thought totally different UX pages, unintuitive settings, slow UI, setting up extremely expensive plugins (why till today you need to buy tempo to get basic functionality like time tracking) etc.
It's called vendor lock. Nobody ever got fired for buying Jira
Other products are not for every business, have limited settings - but are quicker, saves you time and are able to be useful since day one.
All of the companies are using Jira differently, even if you're familiar with this, and you have been using Jira in all you provious jobs for years you still need to have onboarding on how does Jira works in current company - as for instance I've worked with Asana in 3 totally different companies and workflow was the same.
Most companies don't need "comparable functionality" and most did not built entire workflows around it, and those companies will leave for competitors. The few that locked themselves into Jira will face sharply rising prices in next years, that will make them reconsider their choice.
They have bad products and they are losing 700 million a year, future for Atlassian is bleak.
I like to call Confluence a knowledge cemetery - in the huge datasets you have in mind, finding the page you are looking for is more a matter of luck than anything else. And once you found it, you can never be sure if it's still up to date.
> Anyway, they have 8000 employees... they can always drastically downsize and refocus, the company will be around for a while.
I'm actually wondering how they can not make a profit with the huge corporate user base they have?
Spot on from my experience using it in big orgs.
The issue IMHO is that organization of knowledge is not following any system and/or no system that could be followed was ever set in place by the organization when they bought into Confluence.
It's kinda like ordering an Airbus because they're a reliable plane. Then you sell tickets and everyone is board of course because ... Airbus. But you never hire a pilot.
If organizations using Confluence had at least one full time "Wiki Master" position or the like (with resp. superpowers), this wouldn't have to be like that.
I.e. I'm not sure the argument can be made that this is Atlasassian's fault.
As someone who spends a lot of his work life administering Jira and Confluence, I disagree. The problem is that these products try to be everything to everyone and as a result users have a massive degree of freedom with what to do and how to order things.
With that amount of freedom you just have a bunch of end users, many of them non-technical, who have no idea how they are SUPPOSED to use it. Especially because they don't want to spend a lot of time learning the right way to use the tools. They have a bunch of other things to do and just need to interact with this tool to complete their current task and then move on.
You are right, a sort of Wiki-Master would help. But, at least in my organization, we don't even have enough capacity to do all the basic administrative tasks required like setting up projects, workflows, custom fields, screens, etc. We can't also manage the content inside. The users are on their own in that regard.
If you are not willing to hire stuff with the sole purpose of managing the content of your Jira and Confluence instances, a more opiniated, rigid product is probably a lot better for your organization.
I think part of the challenge is finding and retaining this person. It takes a fairly unique kind of person to want/enjoy a (let's be honest) thankless job like managing and maintaining a huge corporate wiki.
Finding good tech writers or information science professionals has always been a difficult task in any company I've been at.
Documentation and wiki writing ends up being side-of-desk work for someone else, and so of course it never gets maintained.
Jira - Everyone has the performance issue, to avoid it they tell them to carefully choose extensions and not randomly litter it, especially with extensions that conflict each other.
Confluence - They recommend to establish a proper structure in advance that everyone follows with templates that everyone can use(not the default ones), so that the cemetery issue doesn't happen.
That said, I haven't seen any company who's confluence wasn't a knowledge cemetery. But regardless of how much I dislike Jira, I'd still pick confluence over google docs.
But what about storing documentation as flat files in version control?
What about even storing tickets as flat files in version control?
I agree that any approach should not have many hurdles!
It eventually got replaced by some JIRA-like monstrosity, I don't remember which. All the text-based goodness was lost. The excuse for the move to a different system was "performance", which was half true. I'm guessing that nobody wanted to go fix it.
The point behind all this rambling is that yes - flat files can be made to work in the way you mention. It just isn't an approach that is cool enough.
Of course it doesn’t apply just to confluence, but to the whole paradigm of uncurated, informal knowledge dumps.
Unless there is a real process around documentation, it just rots, and the key problem is you can tell what’s fresh and what’s rotten.
I've been using https://github.com/just-the-docs/just-the-docs and find it much easier, nicer looking, and people are excited to not use Confluence.
If Atlassian wants to be profitable, they need to replace their founding CEO's. Mike and Scott have done well to grow the business, but the required skillset is different from this point on. Mike in particular seems to be very distracted these days.
The problem is you can’t much go ala carte - you have to go all-in.
But I didn’t use Jira for years. I hope I never will. To the degree, I’ll need 20% more pay for comparable job if they use Jira.
Space wasn't there yet. IIRC the main issue was lack of a way to set custom fields via API, or some weird restriction around that. My general impression was that it was promising but too immature at that time.
For any Jira competitors reading this - start with providing 2-way sync between your product and Jira instance. It would make moving away from Jira soooo much easier! The current state is that even importing Jira data is below what I'd expect - e.g. Linear (last time I checked) didn't import comments at all and all issue IDs were changed to new ones. Really, if there's FOO-123 in Jira it's table stakes for it to be also called FOO-123 in the new tool.
I wrote a tool to migrate an issue tracker to Jira which imported everything as expected and updated links in issue descriptions/comments to keep their integrity. It took few days for a one-time migration so I'd expect someone who builds a business in this area to just have that as a baseline. It's sad how bad the "import from Jira" journeys are.
Caveats: new job is small so it's a small instance. JetBrain's own YT instance is pretty fast though, so I guess it can scale well. Also, we don't use the new KB/wiki feature so can't comment on that. It's probably got less features than Confluence. We don't use the scrum features.
Biggest caveat - I speak as a developer. One of the biggest problems with Jira was the culture that surrounds it. Clueless PMs who had never written software in their life kept creating fixed workflows in which you couldn't transition tickets to arbitrary states (for no apparent reason, there seemed to be no benefit to these rules). So we were constantly being slowed down by the need to get the handful of people with Jira access to edit the workflows and add more transitions, which was pure makework, especially as even figuring out who the admins were was remarkably complicated. PMs also had a weird Jira fetish, they were like, if it's not in Jira it doesn't exist. So they forced the project to change from a more normal SW dev project early on to mandating that every commit had a ticket associated, and that ticket had to be scheduled into a sprint etc. It was just rank stupidity. Want to do a quick refactoring, as part of your current task? Roll it all into one giant commit because otherwise you'll need to file a ticket. New place doesn't work like that. YouTrack is used more simply, like a todo list. Git logs are the source of truth.
My main problem with confluence is that it doesn't know what kind of text editor it wants to be. Sometimes its markdown (or rather its own undocumented flavour of markdown), sometimes its a rich-text editor, sometimes its just plain text, and you kind of figure out on the fly what to do. Also the codes boxes are absolutely massive and a bit of a pain to work with (which, like all of these problems, could be solved with just normal markdown).
In the grand scheme of things though, its a minor annoyance.
Every time there is an update I wonder what feature they removed or is broken. I still cannot properly add images in lists or continue the numbering in a new list to work around this "feature".
They also broke markup/down import which is another kind of hell.
Confluence is the single, worst Atlassian product, in my opinion. I describe it as a wiki written by someone who has never used a wiki. It seems like everything about it is wrong in some way, and it's painful to use.
Footnotes? Ha! https://jira.atlassian.com/browse/CONFCLOUD-68553
I think you misunderstand the way some companies work... Some companies, a VP will send an email saying "As of next week, we will use Asana instead of Jira. Jira will be deleted, so copy anything important off it now. NO EXCEPTIONS!"
Sure, there will be mayhem for a couple of weeks, but the migration will be successful. The VP will have one more thing to put on his 'done' checklist.
But there is no competing product (suite) that offers comparable functionality and provides the same long-term flexibilty.
This is maybe true, but the future belongs to more flexible software. Eventually Notion [1] or Fibery [2] will replace Jira. They may do it now for smaller team already (10-500 ppl), it just takes time to enter large companies.
[1] https://notion.so [2] https://fibery.io
They want to hire 17000 more people: https://www.bloomberg.com/news/articles/2022-04-07/atlassian...
Jira is fine. Atlassian will be around for quite a bit, imho. They have a somewhat decent ecosystem, which helps a lot with the stickiness.
Jira could see a lot of improvement product wise, but at least it has been getting faster in the last year (still slow, though, but not as bad). Their new stuff seems to be a hit or miss, but I especially like their new Jira thing (Jira Product Management), mostly because it comes very opinionated.
I think Jira/Atlassian would benefit a lot from actually providing more guidance on how to properly use their product(s) depending on team size (e.g. moving from 5 to 50 to 500 person teams). Most other tools don't do this as well, but I think that would improve the experience for everyone, dev & mgmt alike..
Netflix, has recently excited the fundamental/rationalist investor camp. The huge valuations hot tech companies enjoy must eventually be justified by a "Thiel Monopoly." That's the only way to earn the 20%-50% margins that Google/Apple/Meta can achieve. Netflix sells a cheap consumer product. One product among several similar options. Consumers are savvy, with many jumping between subscriptions for deals and variety. Content producers have market power, because multiple buyers.
In short, textbook microeconomics is afoot. That means competition, efficiency and low margins. That means "startup economics" don't apply. The market is not going to let Netflix sit on massive margins and monopoly market share. Newschool tech investors see this as an abomination. Old schoolers see it as cosmic justice.
Anyway.. those who desire market rationality love Netflix and are applying the Netflix analysis to everything.
Atlassian is a different story entirely. They actually sell software. Enterprise software, really. There are no content producers squeezing them for a bigger cut. The companies who pay them aren't price sensitive, and they are locked in enough. This is not the "microeconomic normality" monster that bit Netflix. Atlassian's business model is fine. Competition isn't the problem, and neither is consumer bargaining power.
Atlassian's problem is that they haven't done good enough. The bar, set by both tech history and the $150bn peak valuation, is that Atlassian becomes a microsoft.. at least a SalesForce, IMB or somesuch. Where's Atlassian's challenge to AWS? When is Atlassian leading the WFH revolution. How will Atlassian become the organisational nervous system of the modern knowledge firm?
It just doesn't look likely that Atlassian is going to achieve that kind of big-hairy-goal. The products have a crusty, uninspiring feel. The take over the world vibe is missing.
So... Atlassian's valuation is down. I doubt the share price will ever approach "rational." Software companies have value, and the floor is set by opportunistic M&A. If stock markets don't want TEAM @ 10X revenue or more... someone will buy them.
I doubt this is true lately. I have seen even more critical ticketing system like ServiceNow/Cherwell/Remedy getting replaced. We replaced Slack with other chat software because of licensing cost. Big companies are not price sensitive seems like old theory. Because I am seeing in so many large companies increasing license fee is causing replacement of existing products.
Forgive my math skills at 4:07 in the morning, but isn't that actually 36% growth?
> Atlassian’s legacy Jira product ... is no longer loved by developers.
As a developer I prefer Jira over every alternative I've tried (Clubhouse, Trello, GitHub Issues, and Monday.com).
> 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).
That seems like a pretty big hassle though. My company is way too busy to undertake switching ticketing systems.
I also prefer JIRA, but that doesn't mean I love it. It just so happens to be the only available product with most of the features I need.
That being said, its UX is beyond terrible. The moment something else appears that covers some significant portion of its feature set, I can see a lot of people making the switch.
I think one of the biggest problems of competitors is to think that JIRA is bad because it's complex. Therefore they position their offerings as a simpler slim down version of JIRA.
Big news: it is complex to manage complex projects. JIRA has, I think, the right level of complexity and flexibility to tackle that.
If any competitor reads this message: please, go complex!
Yes, (2.04-1.5) / 1.5 = 0.36
In the end - if you're an investor that's exposed to Atlassian, these things do matter. And the article is being fair on that point - do you think Atlassian is worth what it's worth, and if so - why? If the answer is "customer lock-in" and "no real competitors yet" well, plenty of companies in the yesteryears were also in that spot.
How is Oracle doing these days anyway?
https://investor.oracle.com/investor-news/news-details/2022/...
I can tell the reporter has never used or operated something as integral as a ticketing system at scale. These systems are integrated everywhere to automate operations flows. They’re used to continuously enforce compliance. The list goes on. Ripping them out at an enterprise company is very painful. Then on top of all that, you have to re-train everyone on how to use a new system.
In 1991, Microsoft had 8000 employees. It was producing DOS, Windows 3*, Office, OS/2, tools and compilers. Windows NT was in development.
They did not use Jira.
I think the main feature of these tools is to make people, who would otherwise be unproductive, feel and look productive. Maybe those people are managers that should never have managed software development. Idk.
(https://www.landley.net/history/mirror/ms/microsoft_company....)
False analogy. The point here is that productivity in old Microsoft was far higher, and that the failing piece in modern development might not be the ticket system.
That sounds virtually impossible to prove between unequal situations, and especially "far" makes it seem like an exaggeration / tall order (productivity between people isn't like wealth or popularity: some things change by multiple orders of magnitude, but how hard you can work doesn't, especially when averaged across thousands of employees), but to be fair I didn't read the whole fourteen thousand word source you added so I suppose I can't say for sure.
Tell us you don't have any experience with hiring, without telling us you don't.
If this was true; it is not an "efficient market" we are observing, neither in SaaS or developer employment. These companies would be outcompeted. The underlying mechanism that enables this is probably SaaS/etc lock-in.
Will be interesting to see what/how overturns whatever paradigm this is.
They can afford all those useless employees because software allow you to get lots of profit with little work.
gee, the markets were wrong but now they're right! Lucky that.
- not that I think tech stocks aren't overvalued, just addressing the poor logic.
Let me go ahead and flex my MBA knowledge for all the engineers in the building who claim that MBAs don't know anything about business...
First, I suggest you read Atlassian's balance sheet and income statement. They're a public company, so it's all publicly available information. [1]
Look how fast those revenues are growing.
Look at how Cost of revenues is declining against the revenue. In 2019, it was 33%, 2020 it was 28%, 2021 it was 25%. That means that as Atlassian's subscriber count increases, its cost per subscriber is decreasing, a direct contradiction to the claims made in this article.
In the statements of cash flows, you'll see that Net cash provided by operating activities increases every year. Financing activities explain losses, not any sort of problem with the fundamentals of the business.
And, when you're losing money, you don't pay taxes. Atlassian is doing a standard business/accounting play here: re-invest in the business and use financial activities in order to pay nothing to the Australian equivalent of Uncle Sam. Income tax expense is a negative number on the balance sheet each year.
The worst claim in the article is that Atlassian represents a "legacy" product. No, not at all, especially if you've been on their cloud products anytime recently. The cloud products get rapid iterations and improvements, including performance.
Atlassian's pricing is extremely competitive, acting as a "bundle" that competitors can't match. Jira in particular has basically no realistic competitor, and OpsGenie does the same thing as PagerDuty at a fraction of the cost.
[1] https://s28.q4cdn.com/541786762/files/doc_financials/2021/ar...
(Scroll to page F-5 about 105 pages in)
If Atalssian has a revenue (not profit, revenue) of $2.95 billion, how on earth can the stock market capitalization be $162 billion? If that was the profit, there would be a yearly interest rate of 2% on the stock value, which is pretty good in today's financial market conditions, but it is the revenue of a 20 years old company that never had a positive PE. What is the expectation of the market? A new killer product? Total dominantion of the issue tracker market (which btw also includes Github"? I do not get it.
I think the expectation of the market is pretty simple, Atlassian grow by 30%+ YoY for the foreseeable future, which isn't totally unreasonable, and that their costs aren't going to scale with that growth because they're a software business.
If they grow 30% YoY for the next 5 years they'll be pulling in $10Bn in revenue, and maybe sales scale proportionally so call that 25% of revenue, R&D stays more or less flat at $1Bn - let's double it to $2Bn to be generous, Administrative stays fairly nominal at 500m. Hey presto, you've got a company with a tidy $5Bn annual profit. Discount that back to todays prices and that doesn't sound crazy. And all that is assuming is that Atlassian is fully matured in 5 years and not still growing.
To be clear, this is all just very hand wavey numbers, but it's not totally incredible.
I don't think they should be valued as a pre-profit/pre-revenue growth stock - as the article says - the product doesn't really have network effects or strong lock-in.
Any new company probably wouldn’t use it though, it’s just overkill.
It's very affordable for growing startups and its customisability is really useful.
Sure Jira has lockin, but so does any tool with any features. Git has lockin, but you don't hear of people avoiding branches in case they need to move to perforce.
> Any new company probably wouldn’t use it though, it’s just overkill.
So what should they use instead? The thing about jira is it does the basics well, far better than any of the competitors we evaluated. Sure it's not perfect, but no tool is.
Replace Git with SVN in the comment above.
Also replace Perforce with Git in the comment above.
Then you have a viable argument and a story of mine that actually is a case of exactly that - back when project management for certain projects was done primarily in SVN, there was the expectation to stick to the popular way of laying out repositories, with folders for trunk, branches and tags, a bit like the example here: https://stackoverflow.com/questions/2611237/subversion-repos...
Of course, you didn't really need to do it that way and certain other projects explored other options, such as having features under the root of the repository, like "/ISSUE123" or something like that.
Well, as time passed, it became apparent that SVN just wouldn't cut it (TortoiseSVN was such nice software, though) and that the projects would need to be migrated off of SVN and into Git, to import them into GitLab/GitHub or elsewhere. Those projects all still being in development and having the need to be trace back changes to particular feature requests/issues meant that all of the revision history would also need to be moved over.
The problem with most of the migration scripts, however, was that they broke when you had a non-standard layout and as a consequence of that, you simply couldn't finish the import process and were stuck on SVN. Back then I actually resolved it by rewriting the history of those repositories into the standard format, but it was just a massive waste of time and a headache.
Alas, a sentence like this would absolutely be false:
> SVN has lockin, but you don't hear of people avoiding non-standard repo layouts in case they need to move to Git.
So yes, despite there being certain features and the ability to do something, that doesn't immediately mean that you should jump right in and use them! I might also have a few horror stories about Git submodules, or maybe even using Git LFS with synchronized Git repositories across GitHub and GitLab (of course, the LFS contents weren't sent properly, so no binary assets were mirrored), as well as other such problems.
If you can, stick to a stable, boring and predictable set of core features in any software package.
What happens if you get kicked off AWS?
What happens if Oracle goes broke?
What happens if Sun decides it will not let Java run on MacOS?
Etcetera. Often there is limited possibility for portability (people often thought programming in Java made things portable - they were partly right) but each element of lock in you allow must have a very good reason.
In my experience it is usually not a consideration.
Because at this size and age company, that seems unlikely, you'd have to be very rich already to be able to fund such a thing for so long, and have very strong belief ("any day now!") to not cut your losses all this time.
Which is so necessary when your product is very reliant on integrations because maintaining that kind of software gets so cumbersome over time. The testing alone can sink a team's productivity.
I work for a Confluence competitor and we've based our go-to-market strategy around executing one problem very well as opposed to trying to build a set of products to sell as a suite and it's worked relatively well so far. Business people love the idea of integrations and some of them do act as a force-multiplier in productivity. But they also create tons of headaches for end users and can be very expensive.
They claimed to support Markdown in Confluence – It does not work as good as any decent Markdown parser you can install in any mainstream programming language and does not understand, that within Markdown there can be HTML, for example for heading link targets and TOC. Same for Bitbucket. What are they doing? Letting interns code incomplete Markdown parsers and deploying them for everyone to haunt them with subpar quality parsing? The thing cannot even render a readme.md file correctly in Bitbucket.
Everything is slow to no end, downloading 20+ megabytes (no joke, no exaggeration!) for displaying a friggin git repo and the files list.
Wiki pages that the search function lists suddenly become unreachable.
WYSIWYG editor on Confluence is still a joke and annoying to no end.
Any technical person, who has ever used any decent alternative will run for the hills, before using that unholy combination of software, that is Atlassian. Jira is probably still the best among the bunch of utterly bad experiences and its UI is just terrible. Cannot find anything easily there.
It is not great but the rest is just not any better (as far as I have seen that is!).
Aren't you "prematurely optimising"?
One thing done well is exactly what I want of the software I buy.
It takes a few hours to get a basic process flow going in Jira. It really isn’t hard. And I’m not even a fan of it.
It suffers from unknowledgable administrators.
If you have a person who is running Jira Data Center that is familiar with its internal classes, API, Scriptrunner, Automation for Jira, and the enormous 3rd party plug-in environment, there is simply no comparison. It’s not even close.
To be fair, that’s a pretty big ask, in terms of technical know-how and cost. Even just base Jira is quite complicated to configure well.
FCF:
2019 - $420M
2020 - $538M
2021 - $808M
2021 Numbers:
$1.3B Revenue
$372M S&M Spend
$973M R&D Spend
The author needs a finance course.
Hilarious.
Ticketing systems are very sticky, they are basically the original "no code" system, with years of business processes hacked into them, and users who are accustomed to every pixel of the UI.
If Atlassian is 20 years old now, that means it was over 10 years old (~13) then. Atlassian was an enterprise service company at that point already. What kind of enterprise service company can be expected to maintain a 50% year-over-year growth for nearly a decade? If that's "around double this year's growth" that means they're still growing by 20-25%. That's impressive.
I'm not saying the valuation correction is wrong or that the claims they're unprofitable are unfair, I'm wondering what made anyone think they'd perform better than they have in terms of growth if that growth is already impressive. They sell enterprise services ffs and they're the gold standard outside e.g. Sharepoint.
Maybe the problem isn't their growth rate itself, but attempting to build the business model on an unrealistic growth rate.
Now the remote thing could be fantastic. I don’t know what the building on Harrison St. cost, but between what they save on staff relocations and real estate, there should be some offset in two-three years, right?
Salesforce is an Apple to Atlassian’s orange. I would guess they make more money from Tableau than Atlassian do from Confluence and Jira Data Center combined.
“Tableau Software generated $464 million as part of Salesforce for the quarter, up about 18% from the same quarter a year ago“
What will be the total cost of maintaining a Java app (with deep dependencies) for five years? Will subscription costs increase YoY to match?
Add to that the coupling of disparate products and their code and cultures.
Similarly with decentralized projects like Bitcoin. I have come to appreciate Moxie’s stance on decentralized systems moving more slowly. It’s a trade-off. Can any Bitcoin maxis please tell us why we can’t look to newer projects for solving whatever it is Bitcoin was supposed to do but failed to achieve - be a peer to peer cash system for example? How about other applications like voting… why always and only Bitcoin, a 13-year-old project that barely evolves?
(Hence the acquisition presumably, probably gained them not just the talent but a lot of mindshare and extant SME/startup business.)
Jira and Bitbucket, OTOH, the less said about them the better.
Work goes faster if you keep it in small teams and let them self-organise.
JIRA configuration is pain. Unless you are large enough to afford a dedicated JIRA admin, it would likely make sense to just pay for somebody once in a while to implement the stuff you want.
- default text size is too small, text block widths are often not constrained enough getting the "slashdot unreadability effect"
- 0.5s+ lag when clicking any textbox
- 1s+ lag when clicking any dropdown
- 1s+ lag delay when grabbing and trying to drag-and-drop to reorder items in the backlog
- 2s delay when clicking in an issue in the backlog before the loading starts (add about 2s more for the loading itself)
- "Link issue" using a hyperlink icon. The whole idea of using the word "link" to talk about related issues without spending some time to think whether that's really confusing with hyperlinking
- Error messages about what "might" be wrong with things rather than what is actually wrong: "We couldn't save your comment, it might be empty or have invalid formatting". Well which one is it? Did you really have trouble deciding whether my comment is empty or not? Be specific and tell me what exactly is wrong, or do you want me to binary-search / bisect myself?
I think most of the issues can be fixed by completely rewriting the frontend.
Normally have to ctrl+click to open an issue in a new window, then select the key from the browser's URL field.
I briefly worked at a company with 1,000+ devs. They all used a single locked down Jira configuration.
It had something like 30 columns - it was almost totally unreadable.
But the fact is that if that happened, another tool would be used instead, and the same dysfunctional management processes would just re-emerge. Jira makes micromanagy bureaucratic process easy, but does not in itself cause it.
I might be wrong, but I think those tools are dedicated to something people don't like to do by default (planning, going through bureaucratic processes), so they don't like the tool either.
But for some reason, they convince themselves that they don't like to go through Bureaucratic Processes because of JIRA/Asana/etc... and that if only the tool was better it would be a breeze, when in my experience the process is the real issue, rarely the tooling (even though it surely can be improved)
A bit more seriously - it's not only about Bureaucratic Processes. UX matters. If you need to deal with "Bureaucratic Processes" using a terrible UI, it makes things worse.
Jira's UI is notoriously bad. Very slow. And the worst of all are the UX inconsistencies in Atlassian's products. Things behaving differently in Jira vs Confluence or even within Jira itself. For example, being able to use markdown when creating an issue but not when editing it (or vice versa, I don't remember).
The UI is very configurable and has many power user tools, like their search is very good and has so many features.
The Language for writing text is bad and sadly not even the same on other Atlassian products. Please just let me write markdown.
Confluence is another story. It is one of the better tools for documentation, but it's generally slow no matter who runs it. It has very quirky drawbacks like a page needing to have a unique name in a space even if it is in a completely different tree structure.
The editor itself from confluence hangs so much and has destroyed pages multiple times for me, thankfully the history is decent and you can recover usually.
There are some annoying aspects, but it's way better for our workflow than anything else I've tried (which includes github issues, gitlab issues, OTRS, RT, trac and a few others I've forgotten by now).
There was little to no discoverability, it was slow as shit and the editing tools weren't that good. The integrations to their other products were at the time pretty much non-existing as well. Always felt like it was really basic which made me wonder how it could be so slow.
Any other wiki software were probably better. Mediawiki is free but people still paid for Confluence.
I don't get why people used it and still use it to this day. I dislike pretty much every of their products though, they all suck in my opinion and I have written several JIRA plugins so I had extensive experience with it.
At work we are using a combination of notion and gitlab wiki and are probably going to move to confluence. Gitlab wiki is especially hard to use and thus stuff is under-documented. eg I'm a little project right now, we could use about 20 pages to document bits of it, this is such a pain in gitlab wiki.
I use Jira, it is okay. I think a lot of people here hate it because they associate it with Enterprise paperwork and rules.
You could see PRs related to a given ticket, see tickets in wiki, I'm sure it integrates well with CI (Bamboo/Pipelines?), etc. It might seem small, but such integration makes work more pleasant and comfortable.
We have wrapper functions that allow us to automate all the painful interactions with atlassian software. None of them are clever in any way; they're rote. But without them, we weren't using the services fully, which is sophomoric since we don't have freedom to use other services.
I can't defend the slowness though!
Their forays (acquisitions) into version control have been so amazingly weak. Stash was devoid of even basic features. Now they have Bitbucket:
- they still can't get it to perform adequately after years - it lacks syntax highlighting in PR views - it took them years to get side-by-side diffs into PR views - it integrates with third party tools poorly
I thought maybe the Github acquisition would spur them into recognizing it as a important product category, but I guess not.
All-in-all, a great success story. (Whatever one thinks of Jira the product)
Free cash flow includes stock based compensation. Thats a real expanse and turns negative cashflow to positive. But it dilutes existing shareholders, you would like to see positive cashflow EXCLUDING stock based compensation
In fact, if an investor went by GAAP, he would have missed the entire massive SaaS boom of the past decade.
| Unprofitable Companies 2021-2022
| Airbnb | Dropbox | Uber | Lyft
| Zillow | Peloton | Pinterest | Snap
| Cloudflare | MongoDB | Slack | Spotify
| Elastic | Okta | Fastly
Developers "loving" any ticketing system is a bit of a stretch. To me it's more of a "least worst" preference.
But yeah, somebody should create a Jira ticket for their lack of profitability
tag, estimate, assign, add to epic, put on next sprint
JIRA & Confluence seem to be the best of a bad bunch. I do miss the self-hosted option.
It's worth a look if you're evaluating.
JetBrains Space is another alternative, but I have no experience with it.
Mediawiki is a pain to maintain but nothing else comes close.
Jira is pretty cheap actually compared to Asana etc.
Free up to 10 users, $14.5/month up to 20,000.
- People disagree on whether it is appropriate to focus on growth or profitability at this stage in Atlassian's lifecycle. - I suspect people project their misgivings with the products onto the company.
So I didn't learn much from reading the comments.
I think focusing on improving their products would be more prudent. There's only so much marketing can do when users hate your product.
Does anyone like any Atlassian product nowadays?
CTOs and CPOs affection to useless crap designed to impress clueless managers and hated by everyone who actually has to use it is kind of a common pattern.
Forgot that part