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