Hacker News new | ask | show | jobs
by keithnz 2655 days ago
I've been really unimpressed with atlassian over the last few years.

We started with bitbucket before it was acquired, it was super robust, then once atlassian got it slowly small bug after small bug kept making it into production creating mini headaches and they never seem like its super important to them.

We also have Confluence, which is okish, but again, small bug after small bug keeps creeping in, like at the moment, they have a bug with putting markdown into pages (it's completely broken ). Their attitude is it's a low priority fix and they have no idea when it will be fixed.

Bugs happen, sure.... but this kind of thing says to me that they must be so overwhelmed by bugs that fixing documented features of their product is just not a priority if it's deemed to be too fringe. Maybe they are just getting too big and too removed from their customers? Either way, for me it's triggered a search for alternatives.

9 comments

They just don't seem to care. You research something - after hours you'll end up at their bugtracker, where you can read the desperation of others (often some issues are not fixed in 10+ years). I don't understand their priorities. There is to date still no way to restrict visibility of work-logs on issues - a usecase basically every smaller shop has because the client is often participating directly in the JIRA. Service Desk solves that problem but it's quite expensive and you can't mix software projects with service desk projects. So you have to create linked-issues and have yet another layer of indirection :/

We end up syncing projects with another plugin on the same instance :/

Confluence lacking some robust text-only markup (like markdown or asciidoc or whatever) is also more than lame. It shouldn't be that hard because most macros can be configured by text attributes anyway... Expose that Wiki in a readable markdown format and have me let git... like github gist would be more than enough. I despise using Confluence at the moment...

Gitlab could eat their lunch but they also seem to have their priorities off

You mean we're not going after Confluence or JIRA?

Wikis are certainly not a priority for us. I think if you don't separate the proposer from the person who accepts the proposal the wiki tends to grow stale. So we're betting on static websites with GitLab Pages.

There is a large market for wikis but you would have to use something easier than markdown, which is hard for us to get away from.

We're going after JIRA. In GitLab you can have a service desk on a project with an issue tracker. Do we solve the work-log issue too?

Ohh, I really have to stop making snarky comments here :)

So I actually looked at migrating to Gitlab due our JIRA pains but it's not really possible if you have some already grown setup (it's not exactly easy to solve so no blame to Gitlab here)

- no JIRA import (it's possible with some REST-API fighting), but something easy would be nice: https://gitlab.com/gitlab-org/gitlab-ee/issues/2780

- The work-log issue is not solved as far as I understood the documentation, it's possible to have external users to hide internal projects but once you are on a project time-tracking information is visible.

- From a quick glance over the docs it looks like reporting on tracked time is also not possible out of the box - and probably not across projects - we use Tempo Timesheets on JIRA for that, the slash commands /spend /estimate are probably okay for devs but we also have other users that can deal with the fields in JIRA.

- It looks like the whole custom fields on issues is still in the works (we use that quite heavily) and there is no concept of workflows (we also have some custom setup there)

- Servicedesk looks neat through.

Don't get me wrong - this reads like: I want all JIRA features in Gitlab - maybe that's a stupid idea, for a new project I'd probably just use Gitlab and see how are I come.

Sean already did a great job responding to each point here. Just want to add one more quick one. We are working on key-value labels right now, and we think it will solve many of the problems of custom fields. Feel free to take a look and add some comments. Thanks!

https://gitlab.com/gitlab-org/gitlab-ee/issues/9175

Hello! I'm an engineering manager working on the Plan stage at GitLab, which covers all the areas you're mentioning here.

> if you have some already grown setup (it's not exactly easy to solve so no blame to Gitlab here)

Thanks :-) We do intend to offer a good solution here, so these are valuable points.

> - no JIRA import (it's possible with some REST-API fighting), but something easy would be nice: https://gitlab.com/gitlab-org/gitlab-ee/issues/2780

We added a very basic issues import from a CSV file recently (https://docs.gitlab.com/ee/user/project/issues/csv_import.ht...), as a sort of basic MVC of this.

I've asked the product manager in the issue you linked if we're considering this in the medium term.

> - The work-log issue is not solved as far as I understood the documentation, it's possible to have external users to hide internal projects but once you are on a project time-tracking information is visible.

That's correct. We have https://gitlab.com/gitlab-org/gitlab-ce/issues/27204 open for this if you'd like to contribute there, or even just add a thumbs-up emoji.

> - From a quick glance over the docs it looks like reporting on tracked time is also not possible out of the box - and probably not across projects - we use Tempo Timesheets on JIRA for that, the slash commands /spend /estimate are probably okay for devs but we also have other users that can deal with the fields in JIRA.

Also correct! We have https://gitlab.com/gitlab-org/gitlab-ce/issues/54118 and https://gitlab.com/gitlab-org/gitlab-ee/issues/3803 open for this, but I'm not sure if either exactly meets your needs. Feel free to open a new issue and ping me (@smcgivern on GitLab) if they don't.

> - It looks like the whole custom fields on issues is still in the works (we use that quite heavily) and there is no concept of workflows (we also have some custom setup there)

For workflows you can see https://gitlab.com/gitlab-org/gitlab-ee/issues/2059 and specifically https://gitlab.com/gitlab-org/gitlab-ee/issues/2059#note_148.... We do intend to cover this area, we're just quite there yet.

At my clients, they swear by jira workflows (that's the name, right?). The mindset of "customize everything" seems to be impossible to impact. A strong second is managerial heaven plugins with unlimited ways of clicking and visualizing other peoples clicks. Not sure how to compete with that; it's basically disagreeing about the curvature of the earth.
The service desk feature is nice, but maybe having a form for people to fill out to file a support request would be even better. That way, people can file requests without directly opening their email client.

Just a small thought :)

Thanks for the idea! We have the idea logged here: https://gitlab.com/gitlab-org/gitlab-ee/issues/1734. Feel free to add comments there. Thanks!
Jira Service Desk does come with a portal and forms to create requests (in addition to supporting email).
I was talking about Gitlab Service Desk.
> Confluence lacking some robust text-only markup (like markdown or asciidoc or whatever)

The really irony here is that it used to have that! That was the only way I edited Confluence docs back in 2012 (and before) until they took the feature away. For a while you could dig into it, but pretty much any change you made not using the WYSIWYG editor broke the whole page.

I think the real irony for me is a company that promotes software development tools and agile software development seems to not do it. Things that were working break in production, so clearly no intergration/regression testing (if this happened as an oops! once in a while I wouldn't mind so much ), and they are not working at a sustainble pace. Very hard for them to keep their product rock solid, then intoduce new things, and keep it all rocksolid, and they seem to not mind.... my guess is some kind of classic management probem where given 2 of the following 3 choices :- quality, time, features.... manamgent choose features and time but pay lip service that they should maintain quality, it's not a first class concept at a management level, just a detail that the devs somehow have to deal with because they really want features by a certain time.
I still run the Confluence 3.5 version (off the open net). The WYSIWYG runined Confy. It's an awesome, easy, fast wiki if you just stay at 3.5. And you edit it all in text.
> I don't understand their priorities.

enterprise sales contracts

There is a "suggestion" somewhere that asked them to implement service accounts for API access. They essentially replied with "this is a good idea and we should do this". That post was from 2012 or so, and we still don't have service accounts.
I'm not sure whether you'd prefer the alternative -- to not publish feature and bugfix requests. Like many other companies do.

Atlassian should be congratulated for being open!

I think the Devs are too busy writing JavaScript libraries. Annoyed at how slow Jira has become, I opened up Dev Tools and checked what was happening: the page size was nearly 30MB! Sure a lot of this is cached, but it's still insane.
Maybe it's time for me to sell. I've had their stocks since IPO. The only reason why I'm holding on is because they could be potential buyout candidate. Their current valuation is pretty silly, but then again, it's always been pretty silly.
Atlassian software clears the good enough bar for me, functionally.

But it’s all _so slow_. Every action in the cloud UI takes 2 seconds. I would prefer any other product that was snappier.

We run JIRA + Confluence on a dedicated server and it's good enough for us - give the JVM enough memory (4-8GB) and use HTTP/2.
I'm amazed bitbucket still exists considering both gitlab and github are so far ahead of it. I have to use it at work and its missing half the features I need.
I'm only a Bitbucket user because it's the only way I can get hosted Mercurial repositories. The Mercurial workflow is a lot simpler than Git and was much easier to learn. Git expects you to want to mess with history and accumulate changes into a special "staging" changeset before committing which just felt odd compared to Mercurial where I can commit and then keep amending the same commit.
You can amend commits in git. But it sounds like you're doing it wrong anyway. If anything you want to make more numerous, smaller commits, and that's what staging is good for.
I've had far better success introducing Mercurial to developers new to DVCS - anecdotal only.

Mercurials phase system is really nice, but with git you can selectively push branches. However simple this might seem, it's the cause of quite a bit of friction.

TortoiseHg makes visualizing the tool and repository quite simple, and it covers most of the day-to-day work.

I now have multiple developers able to manage advanced workflows, and unfuck a repository if someone did something braindead. After 1 year with git I was still the only person able to unfuck repositories, and it happend a lot more frequently than with hg.

True. I've never tried hg or tried teaching it to developers but I am still the only one able to unfuck a repository after trying to teach people git (the DAG) many times. I think it's probably because of my background in C programming and having the idea of pointers/references so deeply embedded. Programmers who don't know this already can't seem to get it.
To be fair, hg and git are so similar that you can convert between them almost 1:1. But something about hg just makes it work better for devs new to version control in my experience
Curious, what features do you need that are missing? We use bitbucket but honestly I never log into the interface (because it does seem just like an unnecessary visualization of what I can see on the command line). It's mostly just a hosted backup for our repo.

So maybe I'm missing a ton of awesome features that github/gitlab provide?

The change review interface is awful: no way to indicate when its done and needs to be cycles from either end. I loathe the way in which navigating histories and contexts for changes don't work: if I want to search for a past change by commit message it is grep time.
Atlassian more or less gives bitbucket away, so it checks the box for management who care more about license cost than developer happiness/productivity.
Currently the markdown macro kills itself when you try to use it. You have to clear your browser localstorage to recover (from the console error it seems to contain a malformed json).
I believe this was post acquisition: An old company was on BitBucket (which we called internally “shitbucket” because of the frequent 500s) until we went on-prem to control our updates and mitigate bugs actually impacting us (I think this was “stash”). It was amazing how an “enterprise” system was so unreliable and companies still paid for it.
I still don't know why they still exist.
try using the keyboard to copy paste on confluence. atrocious piece of software. its a matter of time someone else replaces them.