[djsumdog]

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 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.

[stephen_g]

Luckily they do seem to have put some effort into making the administration of each project more consistent (at least between Jira, Confluence and Bitbucket Server). I've definitely noticed that things are slowly becoming more similar each release (and they got a lot more consistant in the frontend last year too).

[tajen]

Their biggest product is JIRA followed by Confluence. Let's look at acquisitions vs internal developments:

- 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.

[wryun]

Nice overview! Don't forget Bitbucket Pipelines (in-house), which is intended to replace Bamboo Cloud:

http://blogs.atlassian.com/2016/05/introducing-bitbucket-pip...

(Atlassian employee here)

[mathattack]

I think it can make sense. When you are a startup, you can make a bet-the-company bet. In fact, that's what your investors want. When you're a mature company, it's much harder to take the risk. (And the risk could be as simple as pulling your 3 best developers off the core product) Buying both the product and the team that built it can make sense, especially if you already have the right customer base. If you do it often enough to get good at it, you know the price to pay, and how to integrate it afterwards.

For what it's worth, serial acquirers generally get good at it and outperform one-off acquirers. [0]

[0] https://ttu-ir.tdl.org/ttu-ir/handle/2346/58897

[timv]

> ~2008: Bamboo (builds) - Acquisition

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.

[m_mueller]

You can add Allinea in there somehwere as Acquisition. Specialized in debugging of parallel code including GPU support.

[jacques_chester]

> Your brand is exposed.

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.

[a_imho]

Have you tried xwiki? Last time we were on a really tight budget, we ended up with it and was very nice. Confluence could only handle our use case with 2 separate paid plugins installed!