41–50 of 132 posts
Seems like the perfect acquisition for handling HipChat's downtime.
I'm also sure HipChat knows about, and is embarrassed about, outages. Shaming them accomplishes nothing.
Earlier quoted context omitted.
Which subset of functionality do you need? Issue tracking? Kanban? A means to align corporate initiatives with dev effort? Defect tracking with built-in links to commits and vice-versa?
Oh right, thanks for asking. Issue tracking and Kanban mostly
Seems like the perfect acquisition for handling HipChat's downtime.
Ouch. I know snark is generally frowned upon, but HipChat and hosted JIRA/Confluence downtimes have been serious issues for us.
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.
Seems like the perfect acquisition for handling HipChat's downtime.
Ouch. I know snark is generally frowned upon, but HipChat and hosted JIRA/Confluence downtimes have been serious issues for us.
One example: it can sometimes take > 5 mins to merge a PR.
Seems like the perfect acquisition for handling HipChat's downtime.
Earlier quoted context omitted.
Which subset of functionality do you need? Issue tracking? Kanban? A means to align corporate initiatives with dev effort? Defect tracking with built-in links to commits and vice-versa?
Oh right, thanks for asking. Issue tracking and Kanban mostly
Another great open source alternative is Taiga https://taiga.io/
Seems like the perfect acquisition for handling HipChat's downtime.
Ouch. I know snark is generally frowned upon, but HipChat and hosted JIRA/Confluence downtimes have been serious issues for us.
StatusPage is a great company and service, so this is really disappointing news in my book. HipChat was great before Atlassian bought it.
I remember when I was doing a talk in Melbourne, another developer told me what he didn't like about Atlassian was that they essentially only had one product (was it Jira? or Confluence? can't remember) and almost everything else in their offering set; they bought from other people and re-engineered to fit into their product line. Having administered, Jira, Confluence and Bamboo servers (all with slightly different i…
- 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 [1], 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 ;)
[1] https://www.atlassian.com/atlascamp/2016/archives/build-amaz... - and you can look at their other developer conference videos too.