jschumacher

Yeah, it definitely used to be pretty bad. But to be fair, it’s gotten better over the past few weeks.

I was at Atlassian during the OpsGenie acquisition and part of that process. Honestly, the biggest surprise to me was how long it took to shut down OpsGenie as a standalone product.

The broader trend here is the shift from unbundling to consolidation. Over the past decade, many “features” were created as standalone SaaS products, but that era is winding down. We’re now seeing the pendulum swing back, with more consolidation across the industry.

In my opinion, OpsGenie should have been a built-in feature of Jira Service Management from day one of the acquisition.

It’s a tricky balance. It would be easy for Atlassian to add settings. But every setting adds complexity. And I think we can all agree that we don’t want Jira to be more complex.

It takes a short time to adjust to UI changes, but settings live on forever.

Once you host your videos with Loom and link them everywhere, the moat ain’t that small anymore. Also, their AI features are excellent.

But certainly agree that more competition entered the space in the last couple of years.

The product suite differs significantly from 2015. Put aside new and acquired products like Trello and OpsGenie, the existing products have significantly expanded their capabilities and added Premium and Enterprise tiers.

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.

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.

Great take. I worked on Confluence for a few years and have a bit of insight.

Search has been an area of focus on and off for the most part of the last 15 years. It actually has gotten a lot better and Atlassian has an entire team focused on improving the search experience across their suite of products (they started with Confluence). And from what I hear, they are focusing on all the right things.

To your point, no search system can be a good fit for every possible use-case. Confluence has a number of different use-cases, but let's just pick "documentation" and "intranet" as an example here.

Intranets are, to a large degree, about keeping up with what's new in a company. Therefore recent content is likely more relevant than older content.

When used for documentation, recency doesn't matter at all. If a document was written 2 years ago, but the content is still accurate, it's just as relevant as it was on day one.

That means no single relevance configuration will work well for all use-cases. Leveraging ML is essential. But even a single ML model across an entire Confluence instance is not going to work as different spaces are used for different use-cases. What's really required here is to build different models for different spaces to create a tailored relevancy for each space. It's not an easy problem to solve, but I'm confident they will get there with time.

Seeing the challenges with Search at Atlassian, despite having a large, dedicated team of engineers working on the problem, is what motivated me to join http://sajari.com. We've been doing a lot of work on reinforcement learning and Neural Search. Our focus right now is on public content websites and e-commerce, but eventually we will get around to enable products like Confluence to create a great search experience without the need for an entire team. Search is a hard problem, but there is so much opportunity to improve the experiences that are available today. Exciting times.

I was the head of product for the developer tools at Atlassian in 2012. We thought long and hard about taking Bitbucket cloud and packaging it in a VM (which is what GitHub did at the time) or leveraging the platforms we’ve already built for Confluence and Jira that would give us access control and a plug-in system from day 1. It was a tough call.

Ultimately we’ve decided to build on top of our server platforms and target companies with 1000+ employees from day one. That decision had a huge impact on how we approached performance and what features we prioritised. The hierarchy of projects and permissions associated with them as well as the way we designed Pull Requests are good examples of that.

It was the right decision at the time, even if the product happened to be different in cloud and server, which did lead to some confusion. But Stash customers were really happy with the product.

Bitbucket Server, which some people are referring to here, was build from the ground up, tailored to a self hosting environment.

Not quite. Bitbucket was acquired in 2011, only supported Mercurial and was missing a lot of features, including the pull request available today.

Neural search in combination with learning algorithms and traditional keyword searches are clearly the future. They vastly outperform traditional search engines.

At sajari.com we have been working on an experiment that uses a 1 cpu machine on cloud run to serve a neural network generated, hash based index of an old BestBuy catalog (25k products). Retrieval uses an approximate nearest neighbour (ANN) look up which typically takes ~1msec. Speed and relevancy are already pretty good.

But we have also learned that there is no one silver bullet and we have seen the best results when combining neural search with traditional keyword search and reinforcement learning.

You can take a look at the demo here: http://neural-hashes.sajari.com

Be gentle, this is an experiment and not a production scale implementation.

Every search company will be expected to have machine learning capabilities. However, if you simply bolt them on top instead of considering the fast volume of additional data as part of the core engine, the experience will suffer greatly and the results will be subpar.

It was interesting to see their 30% average conversion rate improvement claim considering they lost a big customer to Sajari after we improved their conversion by 10% (and growing) https://www.sajari.com/use-cases/case-studies/catch-com-au-e...

To be fair, Algolia's marketing is great. They did a great job with the announcement. Looking forward to so how well it actually works and what the pricing is going to be. I don't think OpenAI have announced pricing for the GPT-3 service (which this is based on) yet, but I'm certain it won't be cheap to start with.

We've been looking for an easy and affordable way to share "what's new" with our customers. Finally a pricing that doesn't make this prohibitive for smaller startups.

It's not supposed to sound attractive, but investors will largely care about the YoY growth of 121% for Q2.

They spend a ton of money on Sales & Marketing (293,577k in the last fiscal year). That's what's driving a lot of their growth I assume and it's a lever they can pull back to increase profitability.

In particular for ecommerce sites it pays to invest in search. A large percentage of transactions is initiated by search queries. You are correct that fuzzy matching will likely get you decent results. However, finding the right product 90% of the time or 98% of the time makes a huge difference if you have a high volume of transactions. Synonyms and a better spelling model can massively improve your results and the resulting conversion.

But search relevancy is only one part of the equation. Think about a physical store and how the milk is usually in the back and a few high margin items are close to the counter or strategically placed. The same can be true for an ecommerce store. If the search engine has the ability to take business metrics like revenue and margins, or customer data like loyalty programs or brand affinity into account, you can much better optimise for your desired business outcome.

We just recently switched one of the largest ecommerce retailers in Australia over from Algolia to Sajari by doing the above and increasing their conversion rate by 10%.

What is your preferred pricing model and why?

Interesting change. Disclaimer, I joined one of Algolia's competitors (http://sajari.com) 6 months ago and we are about to release a new product and change our pricing, so I've been thinking about this a lot.

Having worked at Atlassian before, I understand how important simple pricing can be. My personal (and probably biased opinion) is that this is a move in the wrong direction. It appears simpler on the surface, but the concept of a unit and understanding all the disclaimers associated with it make the pricing more complicated than before. If I have to read the faq to understand what I'm getting, it's too complicated IMHO. Also, it seems other features, like analytics retention, crawler, have moved into add-ons, which requires you to contact sales to find out how much you'll pay.

More granular pricing does provide more flexibility, but it also reduces predictability, which can be important especially in small to mid-sized businesses. I'm curious to understand how people feel about "usage pricing" vs. "tiered pricing" where you know exactly what you are paying each month? Which ones do you prefer? We are still finalising our own pricing, any feedback would be very much welcome.

Hey B! Funny seeing you here. I'm now running product at http://sajari.com

You will find that most tools provide document level permissions to some degree by storing user/group IDs on the document and adding filters to the query. However, it generally requires custom implementation work to integrate it into your systems and prevent spoofing of the filters.

Hope you're doing well!

Another correction, Atlassian has offices in Australia, but predominantly hosts their cloud services in the US and Europe.

The plan is to let Trello do what it does best, help people manage anything from organising a wedding to planning software projects.

That's right. We planned the announcement from the Bitbucket side weeks ahead.

I'm a jaded Atlassian user who believes they buy competition and then stagnant the product's evolution.

What product do you think Atlassian has bought to stifle it's evolution? Bitbucket specifically was a product with 50k users and Atlassian has grown it to Millions. Buying a competitor just to let the product stagnate and die makes rarely sense in business.

Let me follow up with our legal team to see why that's in there. Sometimes there is a good "legal" reason for these terms that are not quite obvious to the rest of us.

To the earlier comment, we have gotten a lot of feedback in regards to the sign-up to Atlassian Account. The fact is that you always required a license, so you had to sign-up anyway. But we took the license away and streamlined the sign-up into the product (yes, there are issues with people behind firewalls that we will have to address).

Personally, I don't think requiring an account is asking too much for a free product and down the road it will help us to provide a more seamless integration for people who use other Atlassian tools as well.

Cheers, Jens

I think it's worth mentioning that Atlassian does care, which should show in this new version and the time and effort we have put in to make SourceTree faster and more reliable.

One of our goals over the past couple of years was to simplify SourceTree and make it easier for developers to get started with Git. Admittedly we did not always hit the right balance, but you can be sure we care and listen.

We didn't remove the negative comments from our blog, we removed all comments from our blog to minimise the number of channels on which people engage in discussions. Sorry if it created a perception that we don't care, it's quite the opposite.

Cheers, Jens

That's correct, right now projects in Bitbucket help to organise your repositories into projects. With the raise of microservices, it's quite common that a project or product is made up of many repositories.

In the future you will see us adding more capabilities to projects, such as permission management [1] or settings on a project level, which already exist in Bitbucket Server.

[1]https://confluence.atlassian.com/display/BitbucketServer/Usi...

Disclaimer: I work on JIRA Software

"Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures"

JIRA didn't try to be a universal tool for all processes and procedures, but it happened to spread from the development team into other parts of organisations due to it's flexibility. Of course that flexibility comes at a cost the experience to the end-user is controlled by the administrators.

What is the alternative? A more opinionated tool could potentially get a specific task done better. The problem is that you will need 2, 3 or more separate, more opinionated tools to cater for the specific use-cases. These tools will have to be maintained and probably won't integrate very well, making collaboration between different departments a lot more difficult. That's exactly what JIRA tries to solve, help your teams collaborate.

Could Atlassian be more opinionated. Absolutely. Being opinionated doesn't necessarily mean that we need to limit the flexibility of JIRA. We can do a much better job at optimising for specific use-cases and guiding people towards best practices, while still allowing customisations where desired. We've started this effort last year by introducing JIRA products aimed at specific use-cases. Take JIRA Software for example, it's aimed at Software teams and has specific features like Scrum, Kanban boards, sprints and releases that are specific to software teams. If you aren't a software team, you can just use JIRA Core and you don't need to worry about what Scrum even means.

There is a lot more we can do to make the simple things simpler, and it's a big focus area for us. We won't enforce limits on the number of fields you can add, but we are looking at giving project administrators a lot more autonomy around how their projects are configured. We can't stop the QA checkbox from appearing if somebody really wants it there, but we can provide the guidance and tools to make the experience better for everyone.

Happy to answer any questions you may have.

Great to hear you're already using JIRA and Confluence. Adding Bitbucket to the mix will give you access to a bunch of great integration features.

We've been working on making it easier for the entire development team to collaborate and give them the right information at the right time. Here is a selection of features that I think you will find useful:

JIRA's Release Hub, to let you know if you're ready to release or not: http://blogs.atlassian.com/2015/04/jira-6-4-release-confiden...

The development panel, to turn every issue into a dashboard for it's development work: http://blogs.atlassian.com/2014/03/visualize-development-jir...

Automated issue transitioning, because it's easy to forget to move that issue to "In Review": http://blogs.atlassian.com/2014/08/jira-6-3-untangle-develop...

Hope this helps. For a good overview, you can also take a look at the documentation that outlines the above integrations: https://confluence.atlassian.com/display/BitbucketServer/JIR...

What do you feel is lacking in the Jenkins integration? Bamboo and Jenkins use the same APIs to make build information available within Bitbucket.

SourceTree is an incredibly powerful Git client that has managed to build a pretty strong following with power users who take advantage of features like rebasing or cherry picking.

On the other end of the spectrum we have the folks who are getting started with Git. Even using branches is a concept people have to get used to. Our goal with SourceTree is to make Git more approachable while still maintaining the power of the tool... and yes, that's not an easy task.

As the preview shows, SourceTree will see a number of changes over the next few months, and I'm sure we won't get everything right the first time. But we are convinced that, with your help, we can make SourceTree both approachable and powerful at the same time.

Thanks for the feedback. Sure, there are other ways to accept EULAs, but we chose Atlassian Account since it will enable us to integrate other services like Bitbucket and JIRA more seamlessly with SourceTree in the future.

Unfortunately we can't talk about those great features at this stage since they don't exist.