Hacker News new | past | comments | ask | show | jobs | submit login
Atlassian acquires Trello for $425M (techcrunch.com)
1857 points by SwaroopH on Jan 9, 2017 | hide | past | web | favorite | 733 comments

Very happy for the folks at Trello. Great outcome for a great tool. Seems lots of JIRA-haters in the comments but lets get back and look at this event. The folks at Fog Creek brought us FogBugz, Stackoverflow, Trello.

We should celebrate their success because its events like this that create the motivation for some of us to go create something that "stands on their shoulders" or competes with them or creates some new paradigm of how tasks can be managed. Fog Creek is almost the ultimate startup - they keep it small, do things right, stick to their craft. What is the result? Regularly bring fantastic products to the world. Anybody contemplating how to get setup and run a software startup should start by reading most/all of joelonsoftware and then the later blogs about SO and Trello.

Yes Im huge fan - because i applaud geeks that put heart and soul into their craft as well as running their business and getting great outcomes like this. Would love to see more of it.


> Seems lots of JIRA-haters in the comments

Not just JIRA; I think a lot of people were burnt by Atlassian's management of Hipchat or Bitbucket too.

Historically there's something of a track record where Atlassian is the place where interesting, innovative products go to stagnate. Bug fixes happen glacially (a 1 year turnaround seems to be standard), and new feature development doesn't happen at all. Running Hipchat is like looking through a window back at 2012.

> Very happy for the folks at Trello. Great outcome for a great tool.

Great outcome for a great team? Perhaps. But I don't really see how this benefits the tool, nor the people who use the tool, because I (and a lot of other people here) are assuming, with reason, that this deal heralds the end of further development of Trello.

Do you think the reverse would be true?

If Bitbucket was not bought by Atlassian, it will be able to grow and compete with Github/Gitlab?

If Hipchat was not bought by Atlassian, it will be a serious contender for Slack?

Or perhaps the group behind those products reflected their growth today?

Do you think it is because Atlassian's management or because local's management? Say if Atlassian hold to their words: "we leave them alone".

Or perhaps the issue is Money+Motivation than anything else? Exit => rich => decrease in Drive.

> If Hipchat was not bought by Atlassian, it will be a serious contender for Slack?

We can debate counterfactuals all day, but the potential was absolutely there. Consider:

Hipchat was purchased by Atlassian before Slack even launched. (Slack launched August 2013; Hipchat purchased March 2012.) And back in 2012 Hipchat was almost exactly what it is today: A functional chat app with searchable logs, native clients for many platforms, a somewhat clunky UI, and some persistent issues with syncing and reliability. Further, when Slack launched, it wasn't nearly as good as it is now: They've made significant improvements over the years. Back in 2013 the Hipchat/Slack race was still pretty close, and that's after Hipchat had spent the last year doing nothing.

Slack launched into an opening that Hipchat created by stagnating. It's not that Hipchat could have potentially competed with Slack; it's that Hipchat could have easily crushed Slack. Slack exists now because they built the stuff that Hipchat didn't.

I think you miss my point/question.

Have we ever looked the discussion from a different perspective?

This is fact: Atlassian tend to leave the acquired product alone.

This is question: These products that Atlassian left alone, why are they not growing according to (_yours_ assumed) potential? Have we ever asked that perhaps the people behind Hipchat maxed out their potential? Or perhaps the drive is not there anymore?

What I'm asking is this: Did Atlassian do something destructive after they acquire the company? or perhaps the acquired company just simply can't live up to their potential (for any reasons except Atlassian pushing their management to the acquired company).

> If Bitbucket was not bought by Atlassian, it will be able to grow and compete with Github/Gitlab?

It can't compete now anyway.

> If Hipchat was not bought by Atlassian, it will be a serious contender for Slack?

Hipchat is not even close to being a serious contender for Slack.

That was my first thought too. Jira has Kanban so there's little point for them to improve Trello if they can convert people to Jira.

Trello is more than Kanban. I would imagine their strategy is to use Trello as a beachhead to get less technical teams into using their expanded suite of tools

How on earth is this a good "outcome" for anyone who is not an equity holder? So tired of that word, it's the worst possible one because the outcome is terrible 99% of the time for the real people who actually care about the "outcome"

Hmm... How long does a company have to be around until it's no longer considered a start-up?

Plus Fog Creek is more on an anti-start-up since it explicitly did not want to grow fast at all costs. That's why Trello was spun off.

Do all start ups have to grow at all costs? I know it's standard for most start-ups to accept as much VC money as possible and find ways to spend it, but there are also young companies that don't need VC money and are successful. Don't know why those shouldn't be start-ups.

I work at a company that considers itself a startup -- we're seven years old and completely bootstrapped. I've had many people tell me that we're not a "startup," we're just a "normal company." Usually this comes down to people saying that unless our priority is maximizing growth in the short term, we're not a startup. (We are obviously still focused on growth, just not at the expense of our stability, our product, or our company culture.)

"Startup" is a nebulous term with no firm definition, so these kinds of arguments are bound to happen. Some people still say Facebook is a "startup" because it has the fast-paced environment with the normal superficial cultural trappings of a tech startup (food perks, no dress code, casual interpersonal culture, etc. etc.).

Ultimately it's probably just a dumb semantic argument that's best avoided.

Because we already have the terms "small business" and "ISV" to refer to small companies which are happily making small profits and not trying to take over the world.

Like Trello was?

Perhaps startups just have to look or be sexy to be startups. Successful and boring don't seem to get all the gushing press.

> How long does a company have to be around until it's no longer considered a start-up?

My simple personal guide is: when it has been around for more than 2 years, has found a viable business strategy or is certain to be around for 4 more years.

There is a discussion on this question here: https://www.quora.com/When-does-a-startup-stop-being-a-start...

I think a good definition of what a startup is would consider rate of growth (now and projections into the near future) rather than length of time since inception.

This makes sense. Atlassian is good at making money from its services and it is increasing its overall ecosystem here.

Github moves really slow in comparison. I guess Github is more focused, but there are a lot of contrasts between Github and Atlassian, and in terms of making money I think Atlassian is doing a lot better.

Has Github acquired anything significant? Github should have acquired Zenhub (which is Trello integrated into Github for the most part) instead of slowing trying to recreate it -- although I guess Github has better code purity if they develop it themselves, but it means they move slower.

Thats about all Atlassian is good at. HipChat has become an abomination of a client across Windows and Mac. Every new release is about fixing functionality they broke with the previous release and even then it still isn't fixed.

Logging in from multiple places has always been terrible. I'll be logged in on Mac and available but randomly get emails as if I'm offline. I'll be online on my phone and get e-mails. I wan't emails of messages when I'm actually offline and not logged in but HipChat doesn't seem to care and emails me anyways sometimes. The option to turn off email notifications isn't very configurable either. Its off or on.

Look at the release notes for windows and mac and search for reconnection. Just about every release has a fix for reconnecting going back to 2014.

https://www.hipchat.com/release_notes/mac https://www.hipchat.com/release_notes/windows

HipChat has become an abomination of a client across Windows and Mac.

Ha, try using it in Linux!

And don't even get me started on SourceTree. Just about every release since 1.5.2 is a disaster, to the point of almost non-usable right now.

Really? I'm pretty happy with it. Definitely better than Github desktop, and more full featured than the light git extensions you find in most editors.

What Git GUI do you prefer?

If you can hang with it being in emacs, magit is phenomenal and makes a lot of the harder things (rebase, conflict resolution, etc.) in git easier.

Lightning talk: https://www.youtube.com/watch?v=4ccCNQaTJ10

also, if you are a vimmer use spacemacs to get out of the box, nicely configured vim.

Gitup for the Mac http://gitup.co

Definitely my favourite client, and OSS to boot. I can't really think of much I'd want changed to improve it.

Thanks for this. Apparently I have the Github repo starred but missed out using it. The features look impressive.

Gitup.co is nice

tig. It's been under active development for over 10 years now. https://github.com/jonas/tig

> Definitely better than Github desktop

Not really a fair comparison: SourceTree targets professional devs while GitHub Desktop caters to making git + GitHub simple for beginners. I like the client personally, but it isn't a daily driver. Beyond absolute basics the feature set is totally different.

I'm a big fan of SmartGit http://www.syntevo.com/smartgit/

+1 Smartgit's community edition is fully functional.

GitKraken looks promising, and introduces some new UI concepts (drag and drop merging, for example). It's still fairly young but could be a competitor.

I've been using Fork (git-fork.com), and it's fantastic. Similar UI to SourceTree on the surface, but more obvious in other ways. It's blazing fast, and the author is super responsive to requests and to make fixes.

Thanks for the recommendations, I'll check them out.

Checkout gitkraken. Really easy to use. Cleaner interface than sourcetree with almost all the features.

Gitkraken is amazing

Except that they have recently done an about turn on their licensing, and what used to be a FREE product is now a charge for product.

No problems with paying for a product, but the way they went about the switch left a sour taste, so I went back to SourceTree.

Fair enough, I'm only using it for personal projects, so I can see how that'd be annoying.

In case you missed it, Tower (https://www.git-tower.com – not affiliated) recently got a Windows version. It doesn't have the same level of quality as the Mac version yet (which I've been using for years) but it's improving rapidly and I expect it to be production ready within a couple of months. It's taking relatively long to port because thankfully it is made a native Windows application. Not free, but well worth the money.

Tobias here from the Tower team! I'd like to confirm your assumption: we're indeed working full-steam on improving Tower for Windows (and Mac, of course ;-)

We have quite some exciting features and additions on the roadmap!

Cool, thanks for the tip. I've been eyeing Tower for a long time, but us being a windows/linux shop it's not been a contender until now.

Like what? SourceTree works just about perfectly for me.

I like Tower on macOS, but version 2 is significantly worse than version 1. UI/UX and the number of bugs has been a major pain-point that has made me consider switching to SourceTree. But I still haven't gotten use to SourceTree and GitHub Desktop isn't a great client either as a substitute.

The only major bug I've experienced in Tower v2 is related to renaming repos. That part's very broken, but besides that it's been great for me.

Staging, unstaging, and discarding line-by-line has been extremely flaky for me in v1 and v2. Often discarding a deleted line will insert the line in a completely unrelated part of the file, so instead of a deletion, you now have a deletion and an addition. And so on.

In combination with GitUp, it's still a great tool, but it could need better QA so that even edge cases are solid.

This is different than my experience of Tower and Tower 2.

I frequently pick through dozens of lines of code for a granular commit history, sometimes backing up a commit, saving a commit as a patch, (then) amending some lines to a previous commit, staging/unstaging non-consecutive additions and deletions, etc. and I've not experienced problems.

Renaming repos is straightforward but doing so does not rename the directory in the filesystem. It only renames it in the Tower UI.

To rename the repo root directory, one should copy the origin root directory naming it to the new name and then run

  git init --bare name_of_directory
to create a new repo.

The only trouble I've experienced is deleting branches and tags from Github. Not sure if it's Github or Tower, but deleting those items and then recreating them often yields an error that the item still exists.

(In my defense, the process established at work requires a deploy of a tag to STG once every 2 weeks, but the tag must be deployed to STG every week, leading to a situation where the STG tag must be deleted and recreated. Come to think of it, I'm going to suggest we change our process.)

I'm not affiliated with Tower except as a satisfied user.

EDIT: grammar, formatting, readability.

Yeah, my intent is to rename them in the UI only. For example, if the dir is "my-repo", I might prefer to call it "My Repo" in Tower instead. All of my repos are nested within one or more groups in Tower, which may be relevant.

I've had similar issues with staging/un-staging causing crashes or just hanging Tower.

My biggest gripe is that Tower 1 use to display all your stashes on the side (expanded, not collapsed) by name/date. Tower 2 hides all that information from being easily viewable. I use to use stashes quite a lot, but since switching over I've significantly decreased my usage of it.

Agreed. Instead we can see tags in the sidebar, which is awkward once you have >20 of them (tagged stable versions). I wish tags and stashes swapped places.

Are you seeing the lines get inserted into the file itself or that that's just what the diff reflects? I have experienced the diff in Tower being wrong (getting stale), and while a minor nuisance, it's always been fixed by a restart.

Yeah, the lines get inserted in other places. Usually at this point I just unstage the whole file, fix all errors that Tower introduced in a text editor, and start over.

I've been pretty happy with SourceTree. I wouldn't call myself a power user, though.

EDIT: now that I think about it, there are a few buggy things about it that are frequent but are just an annoyance, not a hindrance.

A Mac user said it should be quite good on OS X, but it sucks on Windows.

It is incredible slow for many operations.

My solution is to use command line git for most operations and SourceTree just for visualizing the repository. It's pretty fine for this.

It makes sense mainly because Trello is a competitor to Atlassian and its best to kill it now before it takes too much market share.

edit: Yes right now there might not be an exact competitor but in a few years it could easily match everything Jira does.

Is Trello really a competitor though? JIRA and Trello couldn't be more different.

I'd think Trello and Asana are much closer competitors. JIRA is like an over engineered spaceship with more features than anyone could learn in a lifetime. Comparatively Trello functions more like a Prius. Priuses and spaceships don't compete.

We don't view JIRA and Trello as competitors.

JIRA shines in areas that (a) have workflow and (b) require repeatable processes across a number of people.

Once you have 20+ people on a project, you need repeatable processes.

In cases like bug tracking, project management, customer service, help desks, HR onboarding and hundreds others you need workflow.

Trello shines in areas where you have (a) small teams or (b) require ad-hoc semi-structured data.

In small teams, even if repeatable process would help you, it's not worth the cost of setting up a system - you achieve it by social means.

Trello also has many, many use-cases where you want to start something quick, or personal. In this case it really shines, with near-zero friction to get started.

Scott, CEO Atlassian

This. I hear a lot of whining about JIRA, which is fair since it's a huge pain to configure and learn all the quirks of, but usually it's overkill for those folks (perhaps myself included right now).

But the folks who have a working process and a large number of people and teams are usually complaining the other way round: that no tool supports their workflow. Which is where JIRA shines. I don't know another tool that can be configured to such ridiculous detail.

The Trello acquisition makes total sense because it fills in that gap that JIRA is bad at.

"We don't view JIRA and Trello as competitors."

You might not view them as that, but they are, well were.

On a side note, I think it's great that you're involved in the discussion here.

I totally agree. Trello is not a competitor to JIRA.

Don't get me wrong – I like them both. When I have to plan out personal projects, Trello is great. During the day, we use JIRA. The use cases are different, and the products are both suitable. I'm madly bemused that people look at the very, very surface layer of the UI (oh look, it has cards in columns!) and assume the products are the same.

Yes, I just recently evaluated switching my small team from JIRA->trello. I'd do it in a heartbeat if the licensing costs were better aligned.

I think Trello fills a niche for people who don't need all of the features that JIRA provides, but they need something to track tickets/cards/whatever you want to call them. The products are pretty different but I can envision an overlap of users. I use both currently and if I didn't have Trello, I might have to use JIRA for everything.

"Is Trello really a competitor though?"

In the Innovator's Dilemma sense, absolutely.

why would they do that though?

Trello covers a market that was not really served by any Atlassian products (or rather, market segments that weren't well treated).

Trello has a huge active following, and a lot of users who would otherwise not know Atlassian products.

Getting any sort of proper cross-selling going on would be great for their ecosystem long-term. People might start at Trello, but go to Atlassian products as their team scales and need other coordination tools.

I don't think you spend $425 million to kill a "competitor", especially when that competitor has a lot of paying customers anyways.

In the context of discussion about mergers and acquisitions, I believe "killing a competitor" almost exclusively means purchasing a company so that it's no longer a threat. In the course of doing so, you assimilate the acquiree's users, or at least try to. This is the meaning I interpreted from the comment you responded to.

The rarer definition, which is that a company actually shuts down the product and doesn't make an attempt to migrate its users, strikes me as something more typical for a small startup that has not yet reached real market validation, but which has very impressive R&D.

Autodesk acquired Softimage and then 3 years later shut it down to great user uproar. Autodesk them tried to migrate them to Maya.




This is too bad, because Trello is much nicer than JIRA for everything I care about...

What does this have to do with h GitHub?

JIRA + Bitbucket (and now + Trello) is a very effective competitor to Github among enterprise companies. Github's issue tracker sort of sucks and this hurts it tremendously -- I know as I live with that shitty issue tracker in an enterprise situation.

Personally all my own projects are on bitbucket. They were the first to provide free unlimited private repos and just has a great set of tools. So my personal preference is bitbucket over github.

They also support Mercurial, which I personally find to be a way better scm tool than git.

Not trying to start the classic hg vs git debate, just saying that it's great to have the option.

It's not better, it's just a million times more usable. A Ferrari is nice, but for day-to-day stuff I'd rather use a Volvo :)

The trick to git is figuring out the subset of commands that make it work like a Volvo

Why do that if you could just use hg?

Because everyone else is still using git.

There is a Mercurial extension that allows you to use hg commands to interact with a git repo


My experience with hg-git has been that it is not always a great citizen with git repos and it can cause something of a mess. (This is a few years old now, because like the rest of the world I switched to git; it may have improved in the meantime.)

For some reason the enterprise version doesn't support mercurial, it's only git.

The reason is it's a completely unrelated product (previously known as "stash") that Atlassian pretends is somehow connected for branding reasons.

Yep, the two products are even written in separate languages!

Bitbucket Server is written in Java and bitbucket.org is written in Python.

I was dumbfounded when I found out they were two separate codebases.

I thought it's like JIRA. Or is JIRA self hosted also different from the cloud version?

I don't understand what you mean by "like JIRA". Remember all these Atlassian products have been acquired as what were originally separate companies.

...grumble grumble...Skype for Business...OneDrive for Business...

(hate it when companies do this)

It's because mercurial is legacy, like darcs, bzr, monotone, and the other zoo of "git-alikes" that were big in 2008. Now it's just like MacOS Classic in 2000: there are a few die-hard zealots who claim that the interface is better in some indescribable way, and everyone else has moved on.

Does this look like the commit log of a legacy product?


Mercurial is very important for Facebook, Mozilla, Google, and others. The disparaging "legacy" monicker might be a good way to feel justified to not have to learn about it, but it's not dying software that is no longer getting updates.

Speaking as someone that works with Mercurial on daily basis, and also makes/sells software that supports Mercurial. I can tell you it's far from beeing legacy.

Some people work with COBOL on a daily basis. It's still antiquated.

What determines if a technology is considered legacy is not if there exists someone out there using it, but rather whether there are people actively adopting it at present. In this regard, Mercurial has slowed down and Git has clearly won the game.

There are companies adopting mercurial as they VCS of choice, either by moving out of svn, or choosing a new VCS

Bitbucket server is written in Java while Bitbucket.com in Python. Those are two different products. That's why the Enterprise version supports only GIT.

Check our RhodeCode for Enterprise SCM tool that supports Mercurial too.

Is RhodeCode still Pylons or have to migrated to Pyramid?

It's now based on pyramid 1.6

Atlassian has cracked the enterprise sales nut completely. Github is still struggling with it some. Completeness is a big reason for that.

And I hope GitHub stays incomplete! I don't need hierarchical access control to decide who can add, remove, and list issue labels, or whatever, just because some pointy-haired enterprise boss came up with that idea five minutes ago.

I hear you, but a simple folder system sure would be nice. Not organizations, just: Client/Project

Nice and simple.

Yeah, and Bitbucket sucks in any other conceivable way, so I don't see why it should be a competitor other than that they shove it in your face once you want to use JIRA or Confluence.

Jira apparently has a reasonable set of Agile tools, with card decks and all.

I suppose that what they are buying, among other things, is a significant paying customer base. These customers can be sold more products, e.g. Bitbucket / Bamboo, provided that Trello integrates with them well enough, or will in the future.

Yah, we're fighting this too. We have back and forth with various devs on our team - some use github, we all have to use Tracker.

Just curious as to what you think Github could do to fix this. I have a list of wishes and I'm always curious what other people have.

GitHub + ZenHub work great.

* ZenHub - Agile GitHub Project Management Software || https://www.zenhub.com/

GitHub + Marker for bugs.

* Marker - Visual Feedback & Bug Reporting Tools for Web Professionals || https://getmarker.io/

GitHub + Unito + Asana even... for clients to get some pretty dashboards without getting bogged down... this works great too.

* Unito - Connect your project management tools and become your team's collaboration hero || https://unito.io/

I love how many things play nice with GitHub now.

Out of curiosity, what are the things you don't like with Github issue tracker?

Personally (and I'm not sure if JIRA fixes this, but Trello gets around it), the biggest issue I have is that Github treats repositories as the only possible context. Say a bug comes in that covers multiple repositories (e.g.: requires a mobile app fix and a backend fix), then you need to create two completely seperate issues and remember to link them manually. This breaks down very quickly. I would much rather issues to optionally exist at an organisation level, with per-repository sub issues stemming from that organisation-level issue.

It also means that someone submitting bugs, say from customer support, must try and figure out where the issue is in order to log it. It's a huge hassle and most just give up and ping an engineer on Slack which is incredibly inefficient.

Trello gets around this by letting you create a "master" issue and link to the individual repository issues. It means engineering can have a bug inbox and triage from there. Still a huge pain and not ideal.

Github also has the "Projects" feature, but it is useless IMO due to the above issue - I wish projects would work at an organisation level.

Where I work you put a jira id in the commit message and it will automatically put a link to the commit in the jira ticket. And a jira ticket can link to multiple commits across multiple repos.

You can use GitHub Projects at organization level now.


You can create organization-wide projects that are not repository specific with GitHub.com.

GitHub issue tracker is free, treat it like that ..

BitBucket is owned by Atlassian and a competitor (the biggest?) to Github in the enterprise.

Imo, GitLab is a more worthy competitor than BitBucket.

I agree with you, to me it looks like BitBucket hasn't evolved at all in five years. The only change worth mentioning is that they made me transition to an "Atlassian account", which was as annoying as when Flickr made me create a Yahoo account.

There are a few new features over the last 5 years...

  * Merge checks
  * Build status (finally...)
  * Audit logs
  * Inline editing
From: https://bitbucket.org/whats-new

Nothing that keeps it above Github, but they always seem to maintain feature parity.

/not a bitbucket shill

//just don't like inaccurate comments.

We're coming up on 6 years now and they still haven't released code search:


That's incredible.

It's okay. It's just that I tried to use it a few months ago and saw they still don't even have syntax highlighting for diffs. It's pretty depressing and it makes it look like they have abandoned the service.

I've been using BitBucket for years and the lack of syntax highlighting for diffs has never even occurred to me.

Why would you want to use such a limited diff tool at all? Personally, I use the best diff tool that I can find and so far that's BeyondCompare from Scooter Software.

I'm with you. I use Araxis Merge. Stupid expensive, but considering I diff dozens of times a day ... worth every penny.

it becomes more important when you use this for code-review. Then reach diffs makes more sense. Once you start using them you don't want to go back :)

I do use diffs for code review. I simply use a much, much better native tool instead of a crappy web tool.

I'm sure guys who have paid for the enterprise version of BitBucket would rather not have to pay $60 for every developer for BeyondCompare on top of what they pay for BitBucket

Yes, nobody would rather pay for anything though - so what kind of argument is that really? It's like saying "Who would pay extra for higher quality tools?" - the answer is: Lots of people would.

Personally, I pay for the best tools because they're worth the money. For that tool in particular, I paid $60 over 3 or 4 years ago. It's practically nothing compared to some of the other tools that we use.

You can use BeyondCompare. I just use vimdiff.

we need to make the web ones get the same experience level then. It's great to have it all there. Were you leave your inline notes, there's a live communication part, all feedback from automated code checkers etc.

It looks like they have added it now.

I wonder if they were slow on updating their site because of Sourcetree, which I personally love (especially since it is a cross-platoform [Mac/Win] GUI client).

No they haven't... I just checked. No syntax highlighting for diffs.

Hmm, they show up for me [1]. That screenshot is an HTML file but I also looked at JS, Python and Markdown and all were showing syntax highlight in diff commits.

1. https://i.imgur.com/Av70r03.png

this isn't syntax highlighting, it's highlighting the diff add/removes.


syntax highlighting would be like this, where keywords, function calls, and variables are all different colors.

Thank you for clarifying. I'm not sure why I didn't initially associate 'syntax highlighting' with what it is. I can see how this would be useful when dealing with a lot of information, especially when reviewing another's work.

You can't claim that Bitbucket has syntax highlighting and then post proof that isn't actually proof. Well you can, but why bother?

I just checked our Bitbucket. There's no syntax highlighting for any of our used languages for diffs. There is no option to enable or disable it. When you do a search for it, it's still an open issue in BitBucket's public issue tracker[0].

If you've got some wizardry working that isn't an external script, hook it up.

[0]: https://bitbucket.org/site/master/issues/8673/add-syntax-hig...


We've added 4 big features just in the last 12 months

+ Pipelines + Git LFS + Smart Mirroring + Merge Checks

More here just from Oct 2016: https://blog.bitbucket.org/2016/10/12/scaling-in-bitbucket-c...

Not to mention other features like 2FA, Projects, Snippets, Bitbucket Connect, etc. in the last 2 years

When can I search code lol

Also Pipelines which is like Travis CI built into Bitbucket.

If you're only comparing Bitbucket by itself to Gitlab then you'd be correct.

If you do a fair comparison and compare the entire Atlassian suite to Gitlab, then you see that the Atlassian suite is far more powerful for most enterprise use cases, which typically involve highly customized workflows and reporting in Jira. The integrations with Jira, making it incredibly easy for higher ups to follow overall progress on software projects that are tied to complicated business processes with long lifecycles, to help understand where the enterprise is in its lifecycle on any given issue and reprioritize resources to prioritized tasks as needed.

Nobody has an issue tracker that really competes with Jira in this space, least of all Gitlab.

What workflow or reporting would we need to add first to GitLab in your opinion?

I remember being in a pitch meeting with an engineer who sells to various other enterprises and he said that what's changed for traditional enterprises over the last few years is that, no matter what their industry, they've all kind of woken up and realized that they're software companies too.

A large enterprise that's fully exploiting Jira will set it up for non-developers, indeed they'll set up Jira primarily for their non-developers. HR will have an HR project with the following issue types: New Hires, Employee Disputes, etc., each with workflows with statuses like resume received, contacted to set up a first interview, first interview set up, offer extended... etc. And then you can use all of Jira's existing reporting schemes to help management figure out, if I need to hire someone new for some type of position, how long does that take? Are there differences between different positions? How long does each stage in the process take? Why? Does the aggregate data show some kind of bias - gender or otherwise? How do I make this faster? And so on. The kinds of questions that you can ask when you're an enterprise with established process and not a start-up with the entire company fit into one room.

Internally, even within our engineering division, we've been using issue linking to other projects to get better visibility into why various work items get stuck. If I'm dependent on some internal service for my work item, and that service becomes unavailable for some period of time, I can grab the Jira support issue tracking the unavailability, mark my work item as blocked by that issue, and then that's visible all the way up the enterprise hierarchy. Similarly, I don't have to ask the people responsible whether they've fixed their system yet, my own item updates automatically to show that my item isn't blocked anymore, and I can go back to work.

The main difference between Jira and Gitlab is that Jira is a workflow management tool and Gitlab is a software management tool. Gitlab looks fantastic if I want to start a new software company and have everything be right there in one window for me. But if you put all the software parts in front of all your non-software teams, they'll balk. It's just not relevant to them.

Microsoft has a tool much like Gitlab called TFS, which has been around for far longer than Gitlab has. TFS is also designed to have this one-stop-shop UI, and TFS also never became an enterprise workflow management tool, even though it too has issues and workflows and customizations up the wazoo. It's a product that's targeted to software developers and it knows it, and that's why hardly any large enterprises actually use it unless they have old .NET projects that have been on TFS forever.

This is the benefit of Atlassian's multiple-product model. Jira is management-first. Bitbucket is software-first. Confluence is customer-first. In an all-in-one UI, you have to pick who's first.

The real problem Gitlab faces is how to retain software projects in growing companies once those companies expand and become large enterprises, and need to start to track more generalized workflows. Because if you had to ask what's most important in the Gitlab UI, workflow and reporting is definitely not it.

You're right that large companies have many different workflows. Currently GitLab's is tied very specifically to issues and merge requests, with additional features like labels and milestones. This is a great foundation with which we plan to build on top of. Issue boards is our current area of expansion. But we do plan on further enriching issues themselves, introducing some structure at some point (e.g. "epic" in the language of Pivotal or borrowing from the ideas of JIRA with their many powerful issue relationships (parents, children, clones, etc.), but of course aiming to significantly reducing that complexity. Part of that discussion is here: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058.

With GitLab, one of our goals is to put all the pieces together. We are building out the integrations, step by step, from idea to production. We believe in a world where everyone can contribute to projects. In a large organization, this means diversity in workflows and individuals. Again, I mention that we are focused on really understanding who those users are as part of this exercise. Our UX design team has begun that work and we have already started research on personas. This will further drive our development of GitLab and make sure to nail those other use cases beyond the narrow scope of software development, into allowing companies to leverage GitLab to create software and processes to run their businesses.

In particular, here at GitLab we use GitLab itself for some HR operations too. So we recognize the potential there. And we even want to ship a simple feature for operational support tickets (https://gitlab.com/gitlab-org/gitlab-ee/issues/149). So we definitely recognize the breadth of opportunity and the gaps we still have.

Hey! I am a product manager over at GitLab.

Thanks for bringing up this very relevant discussion. We definitely recognize the shortcomings and we are working hard to improve in these areas. GitLab started out as a software management tool, similar to what you describe. But we are definitely looking to expand in multiple directions. One of them is definitely to make it a tool that is useful beyond just engineers. One of our major thrusts in this area is issue boards. We are considering who the individuals are in a large enterprise that would be interested in issue boards. And we can't solve every use case right away. So we are starting with personas like engineering managers, product managers, and designers. These are folks that may not be very technical, but still are important in the product development flow in a large organization. See this as an example: https://gitlab.com/gitlab-org/gitlab-ce/issues/24686

We definitely have our eye to expand beyond these use cases. So we anticipate getting into areas like road mapping, Gantt charts / swim lanes, etc. But again, we work iteratively at GitLab, so our very first stab in this area is burn down charts to get feedback on how a software iteration is performing. And then we build on that to bigger scopes like roadmaps for business managers, etc. See https://gitlab.com/gitlab-org/gitlab-ee/issues/91 for burn down charts.

In addition, we recognize the rich nature of teams and the multi-faceted of different roles in an organization. For lack of better term, we've called it "team-centered collaboration" in this issue, we start the discussion that we want to go beyond just software-first projects: https://gitlab.com/gitlab-org/gitlab-ee/issues/1295

How do you feel about project management in Gitlab now that Atlassian has acquired Trello?

There's lots to consider and analyze here. But one area of note is that JIRA is already used by many enterprises. But many folks find that despite it's many powerful features, the complexity is crippling. There's a lot to configure. And it's not an easy app to use with all that complexity. This is in stark contrast to Trello, which is essentially a digital agile board. (JIRA has an agile board too, as one of it's many plug and play features.) So if all you need is a simple board and you don't want the heft of JIRA, Trello is great. And now Atlassian can offer that.

The takeaway here is that project management and software tools are inherently complicated by what they have to solve. There's so many different ways to build software and run projects. How do you create the tools to support those workflows so that a new user is not crippled by the complexity? At least in GitLab we are iterating quickly with small improvements every month. But we also have a UX team to design intuitive interfaces and workflows that make sense. We dogfood GitLab ourselves so we understand the pain points (and the complexities!). And of course we develop out in the open to solicit that constant user feedback. As GitLab further matures and we add more features, we are hyper aware that we do not build another JIRA. There is so much configurability and complexity there. It's very heavy. So are iterating quickly, but carefully.

Atlassian now has two products that do the same thing. Jira for the complex cases and Trello for the simple ones.

At GitLab we'll work very hard try to have on product that is pleasant to use for simple cases but still allows you to handle the complex ones.

This is a huge UX challenge but it will allow our users to use a single product for all their needs, so they don't have to move projects between tools when they 'graduate' to the complex one. And it will allow us to ship more features in the single product we work on.

I look forward to seeing that. Many product teams have tried that and failed miserably.

It indeed is hard. I'm happy that we don't have to get it right the first time but that we can iterate. As you've shown with your great work for Jenkins Blue Ocean it is possible to keep improving the simplicity of an interface even for a mature product.

Whats the challenge in doing something that is easy huh? :)

Exactly! :)

Thanks! We have swim lanes. Your request as I understand it is for detailed swim lane progress reporting (from application to hiring by gender) and linking with a status (blocked). I'll ask our product team to have a look.

I very much doubt big enterprise clients use the services at bitbucket.com. Standalone is where it is at, and BitBucket (previously Stash) is a worthy competitor to GitLab (which was pain to setup just few years back). Big companies usually don't move at the speed of javascript frameworks.

"Big companies usually don't move at the speed of javascript frameworks"

Well ;) https://twitter.com/sreuter/status/818614016801009664 ...

Disclaimer: I work at Atlassian.

Hate to be a crotchety old man, but seeing people recruit heavily for JS just makes me like the company less. Really sick of seeing the increasingly-silly bandwagon jumping that goes on in the tech community.

Genuinely curious why you think it's true. Can you elaborate?

I don't use it much, or rather at all so I don't have much to say. GitLab has a more appealing UI than BitBucket (likely more features too), they have a great team who hang out here on HN and respond to feedback very quickly, they are actually focused on just GitLab while Atlassian has a lot of projects to work on, and their rate of development is much faster.

Oh, I meant between Gitlab and Github. I imagine it's for similar reasons?

and Github Project is a very basic Trello clone.

Github Project is to Trello as Bitbucket is to Github.

Guess which two products I use every day, and which two I avoid like the plague.

Trello, Bitbucket and Github are mature products. Github Projects is MVP.

I find it amusing that someone thinks Github moves slow in comparison to Atlassian.

I feel like about 30% of all Github features have been released since the last major point release of Jira and Confluence, which themselves were buggy, poorly tested, crud as well.

How does Atlassian move "fast"? Has Atlassian done.... anything worth noting in the past 3 years?

Atlassian is a bootstrapped enterprise software company. That alone should earn them a lot of respect.

I think that Atlassian's pace matches their customer's wishes. I believe that Bitbucket is more or less on ice, functions as a free GitHub for private repos, and provides an outlet for Atlassian to try to convert people into enterprise clients, and I think this is their intention for Trello too.

Enterprise clients do _not_ like rapid change, so I think that JIRA/Atlassian is on track. In the last 3 years, JIRA has integrated GreenHopper as JIRA Agile, and I don't know what/if anything else they've done, but I don't follow JIRA closely.

Mr..Mrs. Cookie! I love Ice.... In my drinks but not for Bitbucket.

Bitbucket has released some pretty major stuff in just the last 6 months or so. Built in Pipelines are an example. We've got some other stuff coming soon and there is always more in the pipeline after that.


Bitbucket added support for large files and went a step beyond GitHub and Gitlab by adding file chunking to speed things up in a big way. Bitbucket added file previews to help those working with large files like gaming devs. Smart mirroring to helps remote devs work faster. I could go on but I don't want to spam this thread with a feature list.

There's a nice little post here with some things. https://blog.bitbucket.org/page/2/

Do you use Trello instead of JIRA? If so, awesome! It is a great product. We love it so much we spent around a full year of revenue to acquire them so rest assured that big of a bet isn't so we can just convert it into a lead gen tool. We believe Trello can be much bigger that than. (Alas, I can't comment on that right now as it is in deal closure period)

If you don't use JIRA LMK what you use and what you like better. I'm always up for listening to what we are doing well and can do better.

Caveat- if you can't tell I work on BB and JIRA. If you are in SF, I'll buy you a beer & a cookie for the answers, if not I'll just keep following this thread.

Atlassian provides a whole gamut of enterprise-geared software development tools, whereas GitHub has only just recently started actively pursuing enterprise accounts and providing the features they want.

In addition, Atlassian's services are spread out across many products, which can increase mobility. GitHub has only one product, so while they probably have many teams working on many features, there is still one product they can push releases to.

It makes sense for them to increase their overall ecosystem with Slack's growth looming.

This is a great acquistion for both parties.

1. Trello was smart in only taking $10M in VC funding [1]. This allows for a 40x return for it's investors. If Trello were like many other startups, they probably would have taken too much VC money and got themselves in a situation where the VC wouldn't sell unless it was $2B+.

2. Atlassian now has a product that is loved by many developers and business people alike. It will easily be interegrated into their existing stack and it complements their products very well.

TLDR: Both Trello & Atlassian were smart in this acquisition. Couldn't be happier for them (and as a user).

Edit: typos

[1] https://www.crunchbase.com/organization/trello#/entity

> 1. Trello was smart in only taking $10M in VC funding

Trello wasn't "smart" for only taking $10M in funding (and only in one, late, round, which means it only gave away probably 20-30% equity.)

Trello happened to be spun off from an established company, which took care of financing initial product development and growth. This is equivalent to the founders financing maybe a $1.5M round and a $4M round from their own pocket.

Don't try to beat Trello's benchmark in funding strategy, unless you happen to be able to finance the first few rounds from your own pocket.

> 2. Atlassian now has a product that [.] will easily be interegrated into their existing stack and it complements their products very well.

Atlassian would be wise to keep this integration from being too tight. Trello shines as the most general project management tool out there (except maybe a spreadsheet, although that is the one thing I can't bear to do with a spreadsheet), and if it became a developer-centric collaboration tool I for one would probably stop using it, even for collaboration among developers.

$10M in funding implies a valuation of $50-100M, which means a 4-8x return not a 40x return.

Also, I'm pretty sure that investment wasn't for 100% ownership, so it's not like that $10 million turned into $400 million. The return would have to be proportional to ownership percentage.

yes that's exactly what the parent is saying. 10M at a 100M post money valuation is 10% of the company. 10% of 400M is 40M - a 4x return

>It will easily be interegrated into their existing stack and it complements their products very well.

Will it? i use both Bitbucket and Jira at work, and i'm constantly finding myself wondering how two products from the same org can work so poorly together. They use their products to market their other products, but as far as actually integrating things into a seamless experience it doesn't seem like that's atlassian's strength.

In many ways that will be a good thing though, trello will likely remain trello instead of becoming something else to fit atlassian's ecosystem.

Trello, however, is designed for integrations. There are a ton of 3rd party integrations into Trello (some using the API, some Trello blessed that show up in the add ons list).

I suspect Atlassian could easily create some Jira/Botbucket addons that would make Jira a very useful choice for some Trello users for a more structured backend.

Open letter to Atlassian:

Trello are an amazing team and an amazing product, and what makes the product so amazing is how domain-agnostic it is. They refuse at all costs to add any feature that helps use Trello in one specific way over others (e.g. lists = stages in task lifetime, cards = tasks; lists = assigned people, cards = tasks; lists = dates, cards = events, ...), and that made Trello equally useful as a Kanban board, a CRM, or for a beer microbrewery tracking its different barrels and the stages of brewing they are at. The best thing about Trello is when you start organizing your board one way, then organically drift towards a more natural way to organize them, sometimes without noticing as you do. Trello is for processes that you're not sure yet about the right way to manage.

Atlassian is all about development team collaboration. Trello can be used for that, but not anymore than it can be used for brewing beer. Trello shines when you don't know in advance how you will want to manage a project. If Trello became a dev collaboratin tool, I would stop using it for dev collaboration because there are better specialized solutions for that. Keep Trello general. Please.

Thank you for the kind words.

I promise you Atlassian understands why Trello is so successful. You described Trello's core strength perfectly - and this one of the reasons they are committed to keeping it as a standalone service.

(disclaimer: I'm the CEO of Trello)

I want to add to what Michael said above.

In meeting with Michael, and discussing how we could work together, Michael could not be more clear that Trello's success is predicated on is breadth and its appeal to many different use-cases.

This is most clearly displayed in their inspiration page, that includes many, many use-cases:

Keeping this strength alive will be key to Trello's long-term success.

Scott, CEO Atlassian

Hello, you received a reply in another comment about adding more time tracking and reporting to Trello.

This goes right to the core of all of the issues/conflicts bundled into this acquisition from UX details up through to target users and culture clash.

Time tracking is a manager-oriented feature, not a producer-oriented feature. The users producing the work usually resent things like fine grained time tracking and comparitive producer reporting because it distracts from actual work, treats creative or complex processes as though they are part of an assembly line, encourages micro-management, pits quality against time, and emphasizes wage servitude.

Managers can use Trello to stress out their employees too, but not to the extent that JIRA-ish tools enable.

The problem is you are selling to managers who love to micromanage their employees and have nothing better to do than fiddle with configuration, reports, or have meetings with the people they hired to do that.

This is why developers who are smart will probably try to protect themselves by pre-emptively replacing Trello with one of the dozens of free or inexpensive clones before you can start corporatizing it and their company.

Be it for the general use cases or for the software team collaboration, time tracking and reporting features are always useful. As a user of both JIRA & Trello, I hope Trello soon gets all the time tracking and reporting love that JIRA team could add. Congrats and good luck!

I wonder what founders who have sold their companies for a significant amount end up doing in the days after. It would be really interesting to know what's going on in your head right now.

omg, I'm going to have a boss! I'll be working at Atlassian. Lots of stuff to still do in the future to reach our (and my) goals. And now we're going to have a lot more fuel for our engines to get there.

SAAS founder here. Firstly congrats on such a great exit, you and your team certainly deserve it! I would love to know what "more fuel for our engines means"? How much cash you are you looking to burn? From most listed SAAS companies spend upward 80% on sales and marketing. Are you planning to do more enterprise sales?

I'm sure it doesn't mean anything. He just has to sound excited to keep everyone happy.

I obviously have no idea how Trello is structured and whether Michael has any real ownership or not, given its unique history, but in the case of most SaaS founders, when their golden handcuffs expire, they call in rich, because duh, why wouldn't they? Especially after watching the bureaucracy at the acquirer kill their baby.

You'd have to check his "Current Thoughts" Trello list :p

Thanks for an awesome product. How long was this acquisition on your Trello board?

Hey... congrats, dude.

I completely agree with the sentiment, but my gut says this acquisition isn't about Trello becoming a part of Atlassian but rather Atlassian trying to venture away from their set of dev tools.

Why, you ask? As a recently public company Atlassian knows it'll need to grow beyond developers if they want to continue growing at a healthy rate, and Trello offers that exactly. I believe that's why they paid such a hefty price for it.

It just wouldn't make sense to throw away all those users...

> As a recently public company Atlassian knows it'll need to grow beyond developers

Why is that? Why does a company that is good at something NEED to expand beyond their area of expertise? Is is just me who sees this as American Capitalism™? Wouldn't it be better to try to make their products excellent and attract the many developers who are not using their suite? Why the always constant push to grow at any cost?

I'm saying this as someone who has been using Atlassian products for a while. They seem to focus on JIRA and Confluence only, and letting all the other products be 2nd or even 3rd class citizens. Why expand if you cannot keep the software that you already own up to date?

Why do anything? Why should Intel care about mobile or Nvidia care about compute? Why should apple care about phones and why should Google care about cars and email? Why should Amazon care about cloud storage? Why should Microsoft care about Linux? Why should BMW care about electric cars? Why should Toyota care about hybrids?

Because you can as and because there are big rewards for doing it right and you're in a good position to that.

"Because you can" is the easiest answer you can give to anything. My comment was written because I feel like people say that Atlassian MUST expand beyond developers. So it doesn't feel like they WANT or they CAN.

Because their shareholders expect the biggest return for their money. This isn't a problem for self-funded companies (they don't have to live beyond their means if they don't need to), but if investors don't see growth they'll sell shares while it's still at its peak. That's business for you.

Yeah, the insatiable need for growth is definitely a function of the way we've structured the investment markets. Public companies depend on shareholders for capital. Shareholders buy your shares because they think you're going to be worth more money some day. Generally, companies become worth more money by increasing sales and developing new, diversified assets and product portfolios.

"If you're not moving forward you're moving backward."

It's true for any company, and even more true for tech companies. They have to continue to grow for many reasons, including keeping their existing products better.

I personally am not a JIRA fan. We used it for a while and it just really didn't work out for us. The entire experience was too cumbersome and unfriendly. However, that has nothing to do with them growing. If anything, they're doing an amazing job growing with a product that isn't fun to use at all.

They're public, they need to make money for shareholders.

The set of shareholders who would prefer a company return profits / invest in existing products vs risky investments in non-core-competency areas is certainly not empty. If I wanted to invest in a dogfood company I can- I invest in Atlassian because they make developer tools.

> risky investments in non-core-competency

I disagree with this completely. Atlassian is in the business of collaboration tools. They've done that for developers, but it doesn't mean they're only capable of making developer tools.

Also, where's the risk here? Other than the inflated price I don't see any risk. Trello isn't just an idea but rather a real product with a massive team and a ton of users who love it. They've iterated on their platform enough so I imagine many of both the technical and experience aspects are polished enough. What am I missing?

I think Atlassian is indeed acquiring Trello to fit it in with the rest of their suite. This is probably going to be done to the detriment of the other use cases.

On the bright side, this might pave the way for a new product in this space, or some open-source tools which replicate the same basic funtionality.

Open source alternatives are already out there. Wekan is one of the more popular ones. I'm not sure if it has all of the features of Trello as I haven't used Trello extensively. https://github.com/wekan/wekan

Looking at the screenshot it looks more like a ripoff than an alternative. I am an open source advocate in almost everything, but that kind of ripping of / stealing ideas leave a bad taste.

They already have a closed source alternative built into JIRA.

It misses a few of Trello's features (including keyboard shortcuts and checklists) but it's close.

I'm not atlassians CEO but I'd like to think it would be cheaper to build keyboard shortcuts and checklists than to buy Trello.

Those features should take at most a month and cost at most $25k to build.

Yes there are other things that make Trello stand out but I don't see a justification for this purchase if not just to hire the team.

This was put perfectly. I didn't realize that this was the reason I used Trello to organize much of my life until I read this. I would find it a bit confusing if they started making this more developer exclusive since they already have their Jira software, which already fills that role. I'm hesitantly optimistic that they see Trello for what it is.

Have you found that non-techy people are learning Markdown to use on trello?

No, they just use plaintext.

I'm a big fan of Trello but I dread using Atlassian products. I do not have a good feeling about this.

Hopefully Atlassian can learn from what makes Trello so wonderful instead of JIRA-ifying it into oblivion.

Funny how much opinions can differ. I've used them both professionally and I think Trello scales poorly above 5-10 people while Jira is the least-worst option for running a project at any team size.

My experience with Jira is that it depends very much on the managers and executive team who set it up and create the precedents on how to use it.

Jira is so customizable and has so many features that it can be made into a sort of bureaucratic prison that's actively counter-productive for everyone except higher-level managers who just use it to generate countless reports. In the worst case, Jira can be used to institutionalize mistrust in employees/developers.

On the other hand, a minimal setup with kanban boards can feel a lot like Trello integrated into a bug database, which can work and scale quite well.

I will say that even a minimal installation of Jira can be overly complex for small teams of 2-5. This is where Trello can really shine.

True. I had to setup Jira for our team and must say it was an awful experience. Too many options, hidden in unintuitive places, awful (too verbose) documentation... Everything is just so difficult. Horrible UX. But it was still the best on-premise solution I could find. Trello on the other side is a delight to both setup and use.

I think buying Trello was great move for Atlassian. No way could Jira compete with them in the long run. And now they are even safe(r) from new Trello-like competitors. Brilliant move for Atlassian. Too bad for us users... :(

Had to do the same thing but had a different experience. It was hard to dive in and took some time but now I understand and appreciate the core concepts. There are many abstraction layers ("[...] schemes") and IMO that is a good thing. When you customize workflows etc. you can do that without leaving supported areas. Creating and changing a workflow is very easy. Plus, JIRA has a good pricing.

With ~350 employees and many mixed teams using only Trello would be chaos. In key areas we need fixed workflows (-> JIRA).

Right now we are planning to add Wekan (FOSS trello clone) to our toolchain for workflows which are more dynamic (less "C follows B follow A" + smaller teams - e.g. innovation and some planning).

JIRA is so customizable that it brings out the personality of a micro-manager, even in people who are usually not micro-managers. It's interesting to see how a tool used every day can shape thinking and behaviour patterns.

I consider JIRA a code smell: if an organization uses it, I probably won't be satisfied working with them. I don't think it's because of anything especially bad with Atlassian (although I was furious when they removed the ability to edit Confluence in raw mode), as that the managers I least want to work for seem especially attracted to it.

Your comment just illuminated that for me and I think you're right. It's the micromanager's dream, but for good managers it doesn't seem to offer enough over the competition to draw them in. The best I've worked with considered PM tools essentially fungible, and therefore weren't likely to invest in 1) paying for the Atlassian suite or 2) the overhead of getting it up and running.

>The best I've worked with considered PM tools essentially fungible

After taking a class and reading up on project management and trying to get more organized about my own projects, it's basically that. People have been able to orchestrate large projects with nothing more than pencil and paper and then typewriter. The best PMs don't need to force a tool choice.

Yes, but to my point, as you scale up you have to take into account people's varying skill levels and styles. If you can manage a huge project with pencil and paper, you'll do fine with Jira, too. If you are good but borderline, the structure Jira offers (and can be shared between teams/cascaded down) can help.

Exactly. Once a product meets the basic requirements, everything else tends to be complication and frippery. That doesn't mean there's not room to innovate on those basics, but it does suggest you focus on nailing them perfectly.

yeah but their lives sucked while doing that. Good tools don't get the job done if you don't know what you're doing but make it a hell of a lot faster if you do.

> Jira is the least-worst option for running a project at any team size.

If anyone here has ever been confused by the expression "damning with faint praise", I hope this is an illustrative example.

No it's really not. "Damning with faint praise" is when, say, you've just effusively praised something else, and then say that the alternative is pretty good.

The "least-worst option" means it's not good, but all the alternatives are terrible. That's not damning.

Googling around, the definition that comes up is:

> Damning with faint praise is an English idiom for words that effectively condemn by seeming to offer praise which is too moderate or marginal to be considered praise at all.

Which seems about right to me.

It's like writing an employee a letter of reference, and only saying that they're very punctual - meaning that there's nothing else good about them, other than the bare minimum of bothering to show up at work.

It seems to me that saying it's only good by comparison to how awful everything else is falls into this.

No. If someone asked you to recommend two employees, and you absolutely gushed about one, but then said the other is "always on time" and "reliable worker", etc. that would be damning with faint praise.

Saying that one employee is the least worst employee you have when someone calls you for a reference means they are the best employee. It also means you aren't particularly happy with any of them, but that's just adding a flavor to the sentiment that this employee is your best.

Now, if I asked you to recommend a bunch of project management/issue tracking software suites, and you absolutely floored me with praise for one, but said good but forgettable things about JIRA, that would be be damning with praise.

Coming full circle, saying that JIRA is the least-worst option means it's the best option and you just have an ideal in your head that isn't being met.

They're utterly different things, really.

I just wanted to tell you that you hit the nail on the head for what I was conveying. I'm not an Atlassian employee, and I'm not out to evangelize Jira. I'm not happy with every decision they've made lately, and I have particular things I feel are mistakes where they delineate between core product/marketplace.

But when I look at the landscape of tools that I've used that compete with or compete with a part of Jira, I just prefer Jira over the rest of them by an not-unsubstantial margin.

That said, Trello was great for a small team bootstrapping a new product without a lot of external dependencies or parallel release cycles and I hope they let them run independently.

"Damning with faint praise" is a pretty subtle English idiom. In my experience, it's only used to refer to an instance where someone is socially obligated to offer praise, e.g. a doctoral adviser writing a reference for their student, who gives such faint praise that they intend the recipient to infer that, were they allowed to, they would have been explicitly critical. Since the comment author in question was under no such obligation, I don't think the idiom applies.

Incredible pedantry!

It doesn't apply because calling JIRA the least-worse simply isn't praise at all, it's a criticism of all JIRA alternatives.

I think in this case it's meant to mean "project management and task tracking tools are basically always hateful, but I find this one the least hateful".

I once, over a beer, told the development team of a ticketing system that I'd never used anything I hated less than theirs, and they all grinned and said that that was high praise to them.

If you believe you can produce such a system that people actually like to use, rather than finding less hateful than the alternatives, I genuinely invite you to try, because I'd love to have such a thing available to me. But I'm afraid I'll remain skeptical until I see it :)

I don't get the tone of damning. The feeling is "there is no perfect solution, and Jira although with its flaws, is better than other options."

The road to JIRA is paved with other project management software.

This has been the case for >5 years. Nothing at the enterprise tier is half as good as JIRA (some prefer "least awful") and nothing that's built for small teams gets close to the features needed by large teams.

> I think Trello scales poorly above 5-10 people while Jira is the least-worst option for running a project at any team size.

This my experience as well. What are people using that works so much better than JIRA?

JIRA has problems, but it's far better than any other project tracking/management tool I've tried. Managing projects (especially ones with large or multiple teams) is impossible without tools like this, and I haven't seen anything that makes the process painless.

I agree, we abandoned Trello because of how poorly it handled a team of mixed users. It seemed like all the solutions for our problems had to come from browser plugins, which is just a bad proposition when you need a mix of users of various technical capability.

This is also my experience. I like JIRAs search, and writing experience better. And the integration with Github & Bitbucket is lovely also.

To be fair, the two-pizza team stuff is generally speaking quite a good guideline.

If you have more than 5-10 people using each of your task boards, the problems may be more than any productivity tools can really fix.

Yeah, I agree. I've worked with many alternatives but JIRA shines compared to the competition, especially at managing agile workflows.

I don't disagree with this, but very small teams (or sometimes just myself) is exactly what I use Trello for. We use it at home for shared to-do lists, idea boards (way better than Pinterest for us), etc. I realize this doesn't make them much money, but I hope they don't ruin that use case because I haven't found anything I like as well.

Not everyone wants to maintain their own private server, but if you do have one, give wekan a try. I found it to be a good open-source replacement.


Have you tried https://taskcade.com? Good alternative for shared todo lists for my small team.

Fogbugz (also created by Fog Creek) is actually a pretty good alternative to JIRA.

That's interesting. I've used both and would rather use JIRA over FogBugz any day.

Fogbugz seems to really be pushing their cloud stuff though, so I basically ruled it out instantly when I was researching options - it's unacceptable to have to host our code and tracker off-premises on hardware we don't control. Whereas even a small team can run JIRA or GitLab on their own hardware for a very reasonable price.

They still offer an on-premises version though. IIRC, their on-prem version price was fairly reasonable (that was almost 10y ago though)

(I'm the CEO at Fog Creek.) We've updated the on-premise version of FogBugz to be completely in sync with the hosted version, so all the latest features are on both now.

If you're willing to talk publicly, what's the pricing like for a very small, self-hosted group? I'm talking 3 normal users, might scale up to 5 or so.

We're probably too small to be worth your time, but JIRA is offering $10/yr for up to 10 users, $10 more if you want the JIRA Agile features too.

Our pricing is here, you can check it out for yourself: http://www.fogcreek.com/fogbugz/pricing

In short: We cost a little bit more, but include features that are separate, add-on products for Jira, and generally software developers are a _lot_ happier using FogBugz. If you want to know more, just drop us a line; don't want to be too spammy here.

Just want to confirm - those prices hold for the self-hosted "On Site" version too, where you don't have to provide any management of the data and hosting?

Unless there are regulatory constraints (can't expect logic there...), I don't understand this attitude. Are all your dev boxes air-gapped? If so, how do the devs use google, stack overflow, etc.? If not, how is your on-prem setup so very different than one that used SaaS?

The attitude is simple - don't give your code, and especially don't give access to your devops repositories to 3rd party companies who simply don't need it.

If a security vulnerability happens on the public Fogzbugs instance, we'd be bitten by it badly in this sort of situation. In our setup, we protect against that by exposing the JIRA webserver and git servers only inside of our private network.

It's not about perfect security, but it does greatly reduce the attack surface when the server isn't even accessible via the internet. I can't prevent anyone who wants to from signing up for the free trial of Fogzbugs and exploiting their publicly running system - even logged-in-only exploits are possible in such a case.

Not to mention the issues with downtime on these cloud providers. My provider has had 1 sizeable, noticeable outage in the last 5 years. It spanned about 20 minutes. Look at a big, popular cloud service like GitHub - they've had several in the past year alone, spanning hours at times.

I find these sorts of compromises where I'm offering my code and server configurations to a 3rd party company (where basically any admin there is free to read it, or anyone who can compromise their admins) to be rather poor. I'd rather keep the blame within my own company and be in control of our data fully rather than having to worry about whether Fogzbugs operations follows proper security precautions, I only have to worry about whether we do.

Call it paranoid if you want, but I think it's a more than reasonable precaution to not just throw your data around to anyone who asks for it. Especially data which could lead to compromise of servers and customer information. I value my customer's information much more than I value any gains from some easy to use cloud service.

Thanks for the detailed reply. The downtime issue is certainly understandable. I hope you're keeping customer data out of DVCS, but it's true that flaws in your code might be more "discoverable" if an attacker had that code. It does introduce another step into the attack, however, to have to hack FogBugz before reading your code and discovering the flaw that hacks your services. You know your threat model better than we do, but I doubt most carders would bother with that...

I'm not too concerned about someone getting the code, reading it and discovering a flaw allowing for exploit. I'm much more concerned about someone being able to modify code that will be pulled onto production systems by build and deployment scripts (not to mention the build and deployment scripts themselves) which would allow direct access without any need to hack anything beyond the external cloud service. Even a disgruntled admin at Fog Creek in this case could do something like this without the need to hack anything.

Does anyone care enough about your product to actually go to the trouble to do that? It seems that in terms of actual risk management, managing an on premise version of everything is mitigation out of scale with the actual risk.

Besides, a disgruntled employee of your company is far more likely to be malicious than a disgruntled employee of some random cloud services company. What would be their motivation? They probably don't care about your code at all -- but your employees -- they certainly might. Has there ever been a case of a disgruntled Github employee hacking a customer company's production code ever in the history of Github? Has there ever in the history of SMEs been a disgruntled employee that harmed his own company? All the time.

So what risk is more realistic to mitigate? The hypothetical disgruntled employee at a vendor that probably has never heard of you or employees sitting right there in the office with you?

> managing an on premise version of everything is mitigation out of scale with the actual risk.

Once you have these services running they're fairly stable and hands-off, especially if you have them firewalled off enough to not have to worry too much about remote exploits. A little bit of docker experience can do the job here, we're small enough that we don't need a fancy high availability configuration or anything, so it keeps things fairly simple.

Of course a disgruntled coworker is a bigger concern, but one which is easier to control than outsiders are. And that's not to mention the many times in the past that I've seen 3rd party companies hacked to do things like steal Bitcoin wallets via their providers. If it's an easy risk to mitigate, may as well do it.

Yes, code signing is important whether onsite or off-.

Hmm, code signing might not help us due to some specifics of how we do deployments and builds, but thinking a little more about it - what could help in an even bigger way here is PGP signing at the commit level. Git supports this builtin and recently there have been a few pushes for it's support on services. Probably have to hack together a little custom verification script, but I know of no reason that wouldn't be viable.

This would basically resolve my biggest problems with it I suppose, if used fully and properly. Currently comitting with your SSH key basically resolves this issue in the same way, assuming our internal-restricted server isn't compromised of course.

I'd still be a little uncomfortable putting code on 3rd party servers and having any data there at all for stability reasons, but this does make it more viable. I'll definitely be commit signing everything I have on cloud services from now on.

> NOTE: We no longer sell FogBugz for Linux to new customers.


As someone who frequently works on teams of 10 or less this is exactly what I'm worried about. Trello is a great tool for our needs. I've been in bigger orgs that used JIRA and understand why that made sense, but I'd resent having to use it on a small team.

I used JIRA in very small teams but took great care to configure it sensibly (it took quite a bit of work, I'll give you that). Everyone was happy and even commented on how it made life a lot easier than github issues or whatever other tool they used before.

The biggest problem JIRA has is tons of legacy that nobody needs (like subtasks, a pain in the ass to work with).

Configure the tool properly and it's actually quite nice to use, especially in combination with Confluence for specs.

trello can be used to any kind of project you have in mind, I have my reading list there for example which would be hard to replicate in jira. there are cases were you can use trello and jira for the same puporse and I agreed that in those cases jira wins

Trello is a JIRA competitor based on providing simplicity to task boards.

Why would they JIRA-ify it? They would lose their audience who sought a JIRA alternative in the first place. From their blog post on the subject https://blogs.atlassian.com/2017/01/atlassian-plus-trello/ they seem to acknowledge this

I happen to use, and like, both products. JIRA at work (where I want a lot of the features) and Trello for personal/small group projects and even family/household stuff where I just need _simple_

They will JIRA-fy it or kill it. I use JIRA and pay for it, it is hell on earth for teams of 2-5. We looked into switching to trello to reduce overhead but... It cost more for less features. So we stayed with JIRA.

They will kill trello so everyone is stuck with JIRA. Someone please make a trello clone with reasonable pricing, now!

> They will JIRA-fy it or kill it.

Atlassian is not Oracle. I had fears for BitBucket when they bought it, but they seem to have left it alone for the most part.

Sourcetree, on the other hand, got fucked up. How much of that was a strategic decision and how much just plain incompetence (either by Atlassian or the original team), I don't really know.

Bitbucket has been a bit Atlassified a bit.. Hipchat plugins are at the root of the system and it's just a question of time before they require hip-chat to be there for some functionality to work. Don't believe me?

An example of this was the integration of HipChat in confluence. Product was fine but now requires HipChat X amount of plugins to be installed (to be able to insert Emojicon's in Confluence, using confluence own menu's).

Trello was ridiculously cheap. I think you're totally out of luck if you expect anybody to make a clone that's cheaper.

>"I think you're totally out of luck if you expect anybody to make a clone that's cheaper."

Better tell the Wekan team they're wasting their time then. ;-)


It's not a hosted service, its downloadable and open source.

Big difference.

Free hosts that could run Wekan exist.

$10/user/mo for Trello seems pretty expensive to me. It's a very basic product.

Trello, the head-and-shoulders best project management software for individuals and small teams no matter the type of project and despite the literal hundreds of competitors, is "very basic"…

A tool that could save all employees of a company dozens of hours a month for $10 is expensive…

Hacker News, what the actual fuck. The total and complete lack of respect for the art of design, programming, hacking, making, building, leading and creating software around here astounds me.

...it should only need to save you like an hour of one person's time per month to pay for itself for five users. Products can be extremely basic and still be worthwhile in that price range.

They don't care about selling it to you though when they can sell it to the IBMs. To be fair we probably own licenses to everything. I know we have used github enterprise on the watson side.

I was a Trello Gold user before they added the Enterprise tier. They seem to have completely forgotten Gold exists because all of their new features are Enterprise-only. I ended up just going back to a free plan.

Yeah but if my team has lots of inactive users that starts to add up.

> Why would they JIRA-ify it? They would lose their audience who sought a JIRA alternative in the first place.

And yet, Hipchat is a bloated, unreliable mess.

Same here. I love Trello for its simplicity, and lack of simplicity is exactly why I avoid Atlassian services...

I've always thought that the "white boards and post notes" approach to agile work management is the ideal, it's just difficult to achieve on the 'mortal plane' with remote workers, bad handwriting, inability to query / archive etc. With that in mind I really like Trello because it feels very close to a digital version of that ideal. https://cardboardit.com/ is another product in that vein (I am unaffiliated with both products).

JIRA is awful, although admittedly we were a small team when we were using it for a project, which apparently makes it not the best fit. But I really like the other Atlassian products we use. HipChat works well, it's not quite as polished as Slack, but it does the job and it's been a lot more stable the last few months than it once was. Bitbucket is excellent. We moved from Github to Bitbucket a few years ago and never looked back.

I feel the same, but I also think that the products and ecosystems are so different that there's hope they might keep them separated.

prepare for epic cards made of sub-cards and card tasks, all in the name of Agility of course.

They used to have a blurb on their pricing page that said Trello will always have a free option. It's curiously not there anymore:


It says "Free, forever."

Edit: I guess you mean these three blurbs? http://web.archive.org/web/20160505012250/https://trello.com...

Yup. Having "Free, forever" on its own seems a lot less binding.

"If you currently use Trello as either a free or paid user, you can rest assured that we will continue to offer Trello as a standalone service."


"for now."

Like most software companies, Atlassian products are a mixed bag. I've been pretty happy with their FishEye + Crucible tools for source code search and code reviews.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact