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.
