I don’t think you say the same about other competitors right now… ServiceNow? HP SMS or ALM? ClearQuest? I’ve used those and if you consider Atlassian terrible, I’m not sure what words you would use to describe them…
I think this is key. There's so much customization allowed that its easy to get wrong. Your experiences can vary drastically between a well configured instance and a poorly configured one.
For example, of course only QA people can use "Testing passed" transition. Of course there should be x, y, z fields filled out to be able to create the ticket. Well we're at it, let's make sure only the product manager can close a ticket with 'wontfix', and only the release manager can change a fixversion.
This is a really common problem with any workflow tool, where well-intentioned control points get in the way of actually Getting Things Done, both from the perspective of not thinking through all the complex scenarios (what? I have to fill out 5 fields before I can close this as a duplicate??) and from not trusting your employees (don't worry, a jr. dev is not going to re-assign a fix version even though they can -- or at least, they won't do it twice).
In my experience, FogBugz is a little too limited, so I do prefer Jira, but only when used by competent people who understand that the customization should not get in the way of getting things done and it should not be used to institutionalize a lack of trust in employees.
I've had some fairly large teams able to use JIRA without a single workflow customization (especially with Agile). We've added custom fields and such along the way for better reporting and such but there is definitely some mileage you can get out of the box with it.
Standalone product. I think it will be safe.
When Atlassian bought bitbucket it was the place to host mercurial repositories. Now it's a git hosting service that hasn't gotten around to turning off mercurial support yet.
Also, most of the projects I've seen switch to Git have moved to GitHub. Partly network effects, partly Atlassian.
TL;DR: Confluence besides their Cloud is kind of badly treated and documentation for modern and up to scratch immediate plugin development is mostly nonexistent.
Bitbucket is inferior in every way go Github, with a UI that screams feature box ticking. Confluence is a place for documentation to go and die a slow death, and I'm still convinced Jira was entirely designed to keep project managers and mouse manufacturers in business - you can't do anything without fifteen clicks around the screen.
Give me Github, a repository full of markdown files, and Trello any day of the week.
Having administered, Jira, Confluence and Bamboo servers (all with slightly different installation steps, logging and means to connect to LDAP), what he said made sense.
That being side, I really like Confluence. It's an amazing wiki, even though it's a bit expensive (although they do have free open source project licenses) and kinda resource hog.
- 2003: JIRA - In-house
- ~2004: Confluence - In-house
- ~2007: Fisheye, Crucible (code analysis) - Acquisition
- ~2008: Bamboo (builds) - Acquisition
- 2010: Bitbucket - Acquisition
- 2011: SourceTree - Acquisition
- ~2012: Bonfire (JIRA Capture - screencast bugcatcher) - In-house
- ~2013: HipChat - Acquisition
- ~2013: Stash (BitBucket Server) - In-house
- ~2013: JIRA Service Desk - In-house
- ~2014: JIRA Portfolio (capacity management for Agile) - In-house
- 2014: Wikidocs, Doctape - Acquisitions
- 2015: BlueJimp, Hall, StatusPage - Acquisitions
But what's the right way to start a product today? It's easy to make big bets when you're a start-up, but when you already own several products, you're exposing the brand with every decision. If a product doesn't find its market fit on day #1, if you don't support every combination of platforms, if it really fits a niche but if you also expose the product to customers who were not the initial target, if the pricing is wrong, if it doesn't fit a certain usecase => Your brand is exposed.
I understand the trend to reach growth by external acquisitions, then achieve earnings by scaling the product to the Atlassian size. It's easier to explain it to the market, plus you've already proven the features match the customer case.
Because something else in in-house at Atlassian: Going from Server products to cloud products with the same codebase (a real technological performance), developing the Plugins 2 system and the Atlassian Marketplace, developing an internal PAAS platform, hosting microservices , developing a uniform graphic design and graphic library, developing the sales, creating a big conference for their products in CA (named Summit), creating the developer conference (AtlasCamp in Europe), the marketing machine and relationships with journals. Let's give credit to the workers of the shadow: Most of the work that's needed to make great products aren't features.
Maybe, after all, it's a company whose core business became to bring features from niche/luxury/early adopters to enterprise. They shorten the path of good ideas from hackers to IBM-style customers. It's important to us, developers, because they helps migrating big old companies like banks and government to new methods. The features of the software you put in are important, but what's more important is how to massively develop adoption. Man I'd love to be a PM for Atlassian ;)
 https://www.atlassian.com/atlascamp/2016/archives/build-amaz... - and you can look at their other developer conference videos too.
(Atlassian employee here)
For what it's worth, serial acquirers generally get good at it and outperform one-off acquirers. 
Who did they buy Bamboo from?
The first Atlassian releases of Bamboo were so bad we went back to using CruiseControl. I'm astonished that they actually paid money to acquire that.
It depends on the brand.
Software is expected to be improved over time. Which implies a less-improved state as a starting point.
The idea that customers expect you to teleport to the Platonic ideal of a product isn't very realistic.
Why is this a natural fit for Atlassian? Not being snarky, I just don't see how this is any more a natural fit for Atlassian than lots of other companies that provide picks-and-shovels to the software builders of the world.
Their products are decent enough, but certainly not exceptional. Their pace of development has slowed to a crawl. The word on the street is that they're pouring massive investment into HipChat, yet it's been easily outdone by Slack.
Yet, they're doing well, because they manage to package it all up at just the right price point, with just the right set of services to get people to buy it.
Something like StatusPage fits them well because it's an existing, working, solution that they can monetize.
Edit: I see that HipChat's reliability is a big issue for several posters, maybe your installation has that. The ones I've used were fairly basic.
What are the good alternatives to StatusPage?
 - https://cachethq.io/
I'm skeptical that running Cachet on your own servers would be cheaper than StatusPage's smallest plan, especially if you have any kind of redundancy in place.
That is enough redundancy for our little bootstrapped web app until we are large enough to be able to afford something better.
@Everyone, if there is anything I can do to help, let me know! You can email us firstname.lastname@example.org to discuss more.
 - https://runstatus.com
I know snark is generally frowned upon, but HipChat and hosted JIRA/Confluence downtimes have been serious issues for us.
Jira, although it is slow, works quite well for our on-premise version.
StatusPage is a great company and service, so this is really disappointing news in my book. HipChat was great before Atlassian bought it.
One example: it can sometimes take > 5 mins to merge a PR.
The solution for us was to decline those old PRs.
Is Jira so bad to scale in their hosted configuration that it has to be slow for everyone? Our local jira, after some experienced tweaking, was so much more responsive... it's weird.
I'm also sure HipChat knows about, and is embarrassed about, outages. Shaming them accomplishes nothing.
I also felt their blog post was all about their journey, which while interesting doesn't really present any value for us as a customer. It would have been nice to know why the acquisition is in the customers' best interest rather than only the founders' (of course both are important).
Issue tracking? Kanban? A means to align corporate initiatives with dev effort? Defect tracking with built-in links to commits and vice-versa?
Everyone in our development team eventually get used to the names, and everyone loved all the little jokes, so we leave the Serious Business Mode off, though.
On the other hand, you can customize the sidebar, deactivate stuff the team is not using, and such. Default install is definitely overwhelming.
Another great open source alternative is Taiga https://taiga.io/
I've just looked up the cost, it would be about £0.20 to send it.
I did tweet them about it a while ago, but I din't think it really made sense.
most of my encounters with status pages have outdated information such as i am checking your page because i think you are down, but you dont list that you are down, yet. or when they are having a problem, there's a very tiny indicator and somewhat useless message.
what could this possibly bring atlassian that they couldn't build themselves?
AWS has outages too, also statuspage.io own site reports,
Hosted Pages Uptime 99.969%
99.969 != always.
Pricing also isn't too shabby,
Enterprise starts at $1499/mo.
For small 18.000$ a year, one should be able to setup your own external monitoring, with email, Facebook, twitter and what not for hooks to update your users of the service status where the sky is the limit, not the limits statuspage.io sets for your account.
Setting up the statuspage.io, monitoring it, keeping things as they should, adding new stuff to monitor thats not a task one of those 5 will be doing regularly? And what if he does a poor job at that? You end up with what you say, the same buggy level of monitoring. So what _is_ the excuse not to make your own and pay significant amounts of money to a third party?
I say 18.000 is a lot of money for a service that reports your outages (good 3 month salary here, and in three months one can code a lot). And if you do it yourself you have all the freedom of choice how you monitor what you monitor how you report to your users instead of relying on the options statuspage.io offers, there is no limit
And why would your own monitoring be more buggy then some setup a third party deems to be ideal? You can make a perfect fit, gives you another view on your own products etc.
Full control is key, in house solutions, not saving money.
I said 5 developers. My first job was on a team of ~12 developers for a company with 30,000 employees. Developer time was gold and as such the company often purchased products that we probably could have built in house given sufficient time.
> And if you do it yourself you have all the freedom of choice how you monitor what you monitor how you report to your users instead of relying on the options statuspage.io offers, there is no limit
If you need something an off-the-shelf option doesn't offer than you wouldn't be considering it in the first place. If you have truly odd requirements you're going to be forced to build your own anyway.
> And why would your own monitoring be more buggy then some setup a third party deems to be ideal?
StatusPage's Show HN was a little over 3.5 years ago. There's no way you can build something less buggy in 3 months. This is a perfect example of not only developer hubris and "Not Made Here" bias, but the problem of trying to estimate the time to walk up the coast.
And im curious if* you wouldn't have liked it more if you did have more time, resources, colleague to have had the chance to develop those things in house, yourself. And having another product to sell instead of buying a service from a (potential) competitor?
Also i doubt they have been coding for 3.5 years, and if their show HN was 3.5 years ago, very nice promotion for them. But that doesn't say anything about the quality of the product. From what i have been reading over the years from their development they are just integrators of already existing technology. So if you want me to integrate APIs for 3 months, i think i can get quite a long way.... by myself in the evening hours and weekend even.
They started with outsourcing most of their services used (mailgun for mail, twilio for sms, etc etc), so i rather develop something myself, (and yes in 3 months i can integrate a lot of 3rd party services via APIs). So if you prefer to OUTSOURCE, your service to a party that outsources their services again, and find this of a higher quality of service then* writing your own (which give you options to resell that product etc), then i think we just have different view of what quality is.
Nonetheless, weekend is coming, hope you have a good weekend :) probably in case of reply will read it only after
If your site's back end is down, the site itself should be saying something intelligent. ("Ngnix timeout", or Cloudflare's error message blaming the site server, is kind of lame, but it's something.)
If you pay them.