I'd say the user base is as or more important than the product, from Atlassians POV. If they are able to convert a few hundred thousand JIRA accounts from this, they could turn Trello off and it'd be a win.
Yes – Just like Bitbucket Issues didn't marry JIRA. One core difference between Trello and JIRA Agile is, in Trello you can't hide tickets that you don't want right now in the sprint – In JIRA Agile, you only put a few issues in the sprint so the board looks clean.
Anyway. Not sure why some people want to move away from Trello now. Is it that they don't want an identity connection between JIRA and Trello (SSO or similar)?
I think it's likely that people who use Trello appreciate the simplicity and Atlassian aren't exactly known for creating simple software (speaking as a past Jira user/admin).
I had the same feeling of "oh well, what else can I use in the future" when I read this post.
I am a big JIRA fan, but lately they have dumbed it down to be very much like Trello. So I hope this gives me old JIRA back, built-in. Currently I have the "classic" workflow as an export that I can import. I wonder if they will try to push Trello users to Atlassian hosted JIRA Software with the simple workflow, or if they will combine the two like they did with Bitbucket and Stash.
It has been used extensively in our organization too, and our CTO is now searching replacements after the announcement.
We've have been exposed to JIRA through external suppliers and that has been enough to make him on his edges now.
Personally I don't think much will change, at least in the first year or so until the contracts of the original developers lapse and they can move on to new things.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Wekan is really a copy of Trello, it's awesome. Installing it through Sandstorm.io makes it very easy, but I don't have production experience with Sandstorm.io.
I've been using the Github Project board functionality which looks a lot like Trello. I doubt there's an integration where you'd be able to port one to the other though.
Taiga is alright, but I can't say I fell in love with it either. Then again, I didn't like Trello any better. Still ended up just using plain text files or spreadsheets.
Right, but they don't have a good reputation to start with.
Somehow the only good things I heared about them came from people who made their money by building stuff they wanted to sell on the Atlassian platform. People less biased always choose alternatives.
I can't say much about them myself. I only used Bitbucket, because of the free private repos. Their UIs are pretty mediocre, but I use it via Git cli, so it doesn't matter much for me.
So as a counterpoint. I used BitBucket a lot before Atlassian bought them. They were great, but toward the end suffered significantly from load issues.
After Atlassian bought them:
* The service I paid £5 a month for became free
* The stability issues started to improve in a dramatic fashion
Today Stash is a great product (IMO), and BitBucket has really improved from having great Jira integration.
I was actually sad because I couldn't justify paying for the premium features (multi-person private repos) in the same way, because it was nothing I needed. It was the best £5 subscription I ever had :)
I'm in a similar boat. I kinda disliked Atlassian because of my experiences JIRA.
I generally prefer Bitbucket over Github now (was a paid subscriber of Github). I basically use Bitbucket now for private repos and Github for my public repos, since Github does seem to be the place to put open source projects.
If my Bitbucket needs ever reach the point of having to pay for a subscription, I'll do it gladly.
As far as ticket / issue tracking systems and wikis go their products are quite decent.
JIRA has its quirks but it's very flexible and customisable. Its UX is also quite ok for such a complex piece of software. Keep in mind they're competing with stuff like SharePoint and downright UX atrocities such as HP ALM.
Confluence is among the best enterprise wikis targeting end users (i.e. users not familiar with Markdown), too.
HP ALM is awful. The biggest issue is that you needed to install it on the client machine to be used as a plugin. I would rather have Atlassian products than HP ALM and Clearcase!
That's been my experience working with JIRA the past few months. Bug after bug and always a bug report with someone begging for a fix and being ignored.
What's wrong with it becoming a service you pay for? This is, in-fact, what you get when you entrust someone else's Software As a Service with your data and workflows... You do not own it, they do and it is their right to charge for it just as it would be your right to charge for some service you developed and maintained that people found useful. It is also your right to move your workflows elsewhere or to a desktop / laptop resident piece of software that's not owned by anyone!
Whining about a for-profit product no longer having a free-tier is odd to me. Either be fine paying for the service (nothing wrong with that) or pickup software that is free; I for instance personally use org-mode and Emacs heavily for all of my personal information management.
I also do not understand the sentiment that every product acquired will slowly begin to suck; that happens for some products sure but the converse is also the case.
To be fair to Atlassian, I used to hate Jira a lot but in recent years had to use it for work and it quickly grew on me; they are putting effort into improving their services / products, modernizing their software development processes and technologies, and delivering updates to their software on a regular basis.
If you're going to contribute here, please be more constructive or detailed. Why not talk about your ideas for a project that is free that anybody could install on their servers that does what Trello does if you do not like that they may begin charging for Trello?
The fact that Trello got a lot of users by promising it would always remain free, for example? If I'd been a user I'd be rather upset about this sell-out. Fog Creek made it look like some nice side-project that others too could benefit from without ever worrying about having to pay for the basic version at any point. Sure they didn't owe anyone anything, but for me it confirms once again that no company can be trusted on their promises, ever. Now, of course we don't know yet whether the free basic tier is going to change, but we do know that (unless it's in the agreement) Fog Creek gave up control over their promise, which is prerequisite to keep it. Furthermore, I have the experience that few products survive an acquisition to keep the simple, successful formula they used to have.
Edit: fixed unintended mistake in the company name
"In July 2014, Trello spins off from Fog Creek and becomes Trello, Inc. naming Fog Creek co-founder Michael Pryor as its CEO. The company raises $10.3 million in a Series A round of funding led by Spark Capital and Index Ventures."
Spark Calital and Index Ventures must have gotten a nice huge return, Trello only raised $10 million.
All depends on what valuation they got in at. Trello was pretty well on it's way by July '14, so it's possible the valuation was already pretty high. Even so, I bet it was a 3-5x multiple, at least.
Trello has apparently about 19 million users. And I would bet that the majority of them are not the typical target audience of Atlassian products (i.e. software development teams).
So I wonder if they are mostly aquiring the user base here in order to expand their potential market?
That is true - a lot of software developers use a variety of tools so they can do more advanced things like track burn rates, project velocity, and such more quantitatively. Trello, on the other hand, is so easy that I've seen it used for everything from managing speaking arrangements to writing books. It has more of a mass appeal.
Yeah, that's exactly what they say in the article. Their goal is to get to 100MM MAUs, which they can really only do by expanding to non-tech industries, and Trello is extremely popular amongst marketing and finance professionals.
Trello is hugely popular amongst software developers, but I think the point being made is that it's also popular outside that niche. At work it came in through the back door being used for software planning, but quickly became the preferred tool for managing any sort of project. There's a similar story with me showing it to my wife, who just finished managing her PhD in history with it.
I'm a data scientist and I've been using it as an informal Kanban board because JIRA is way too complicated-looking for me want to even try to learn. Trello is about as dead-simple as it can get. There's already too much in my brain.
Bingo... that's the whole idea here. Small teams within larger companies and small companies can use Trello. When they grow up (or need to interact with the rest of the company) they use JIRA. In fact I would expect JIRA integrations that make it trivial to convert a Trello card to a JIRA task, probably with an option to automatically convert a checklist into subtasks.
This acquisition makes total sense; Trello and JIRA target mostly non-overlapping market segments and there are some easy low-hanging integration fruits to be picked. I'll also bet Trello becomes a deal-sweetener going forward. License JIRA and for +15% you also get Trello for your whole company.
Very well said, the larger the company, the less flexibility it has in choosing the right software for the entire company. Smaller teams can move quicker, faster, and tend to find their own solutions within larger corporations.
I know a lot of smaller dev teams use it for lowercase-a agile projects and I currently use it for all my personal projects. It's basically the antithesis of heavyweight tools like Jira.
I doubt they can. I work in public digitization from an it-architecture and programming background, and because municipaliies work closely together on a national plan I interact with quite a few teams.
I've yet to see a project manager or anyone outside hardcore development get anything positive out of at Asian products.
Their tools typically complicates everything to the point of slowing production by as much as 150% compared to projects where management is done with post it's on a board and physical meetings... I know because we did the business case, which today means we're actively avoiding companies that want to tunnel projects into things like JIRA.
I get that atlassian produce excellent tools for tracking development time so companies can bill me more precisely. Unfortunately the side effect is that everything gets produced slower, more expensively and ends up confusing the shit out of our project managers.
I think most of it is about the brand; about buying a name which is already imprinted in millions of minds. The technology alone is probably only worth 1-5% (?) of the price.
2. Create Stack overflow and make it the goto for developers.
3. Create todo list
etc..
The brand was there before they even started the todo list. All it took was a blog post "We are going to create a todo list now" and it was pretty much set.
Why did Fog Creek approved this acquisition? With products like Stack Overflow, Trello and GoMix I thought they want to become a big player on the market of software development. Why sell our own assets?
My sense is that Fog Creek is more of an incubator than a traditional software company now, albeit one which is incredibly selective about what they invest in. Stack Overflow and Trello are both independent companies which started out as side projects for Fog Creek, and I imagine GoMix will eventually go the same way.
Fog Creek's model tends to involve spinning off their runaway hits into separate companies. They've done this with StackOverflow and Trello. Trello has been an independent company since 2014. (Although I'm not sure what kind of ownership position Fog Creek had).
Fog Creek and Trello are two separate companies that share cofounders (and an office here in NYC!) so we at Fog Creek are happy for Trello but it's not an asset of ours.
Trello had super ambitious growth plans but didn't have the leadership team in place to achieve them. They built an incredibly valuable and wonderful product and Atlassian is an appropriate partner to take it to the next level.
Pryor and Spolsky have been running Fog Creek for sixteen years. That's a log of 'everyday at the office' to go without a big payday, particularly considering how much StackOverflow could have been sold for years ago.
From a strategic standpoint, selling Trello is probably a more favorable way for Spolsky and Pryor to raise $360 million in cash than through venture capital. In hindsight it's not implausible that the goal behind developing Trello was always to sell it off. Unlike StackOverflow, Trello has lots of competitors and it's value in is in integrating with the rest of a project's workflow. Essentially it's a commodity.
Can we all start using Trello clones as the tutorial substance? So in case Atlassian screws it up, we have 100s of developers that know how to re-create it? :D
Never heard of it, but this actually looks as if it could replace Trello and Airtable, two products I really like, and then some. Thanks for the suggestion.
Besides being a good one, it also didn't sound like a terrible idea at first. Boards with cards is a suitable simple application for beginners (or people that are just learning a new environment/language).
Then I remembered my difficulty with finding a proper to-do app. Yes, it will have millions of people make a clone, but it will also have thousands publishing crappy versions.
I've used http://lavagna.io for a while on my own servers, but recently I've started using and enjoying https://www.favro.com whose free version has less limitations than the free Trello version.
Some of Atlassian's previous acquisitions have turned into products mostly shunned by the developer community (Hipchat, Bitbucket) - I hope they've learned what went wrong since then, but my gut says Atlassian isn't very good at integrating external teams and supporting their products. Hopefully Trello won't go down the same path.
It never comes up in the same breath as GitHub and GitLab. The major differentiator for Bitbucket that's the primary reason many people I know have Bitbucket accounts - that they offered free unlimited private repos when nobody else did - doesn't differentiate them anymore.
GitHub neither offers free private repos nor Mercurial support. For me and many others, Mercurial support is a big thing.
Bitbucket may still be less popular but I don't see it being shunned. That's what made me wonder. I wouldn't mind if you said that it was not given enough attention or even that it was being ignored (Although I'd still disagree). Maybe bad choice of words?
Even prior to its acquisition. I seriously disliked finding projects on Bitbucket, the UX just seems to be wrong for how I want to interact with codebases and documentation. It's only gotten worse since they were bought.
Why are Hipchat or Bitbucket shunned? Hipchat is a slimmer version of Slack but pretty much does the same things. Bitbucket is just a github with a Atlassian skin.
Hipchat's on premise version doesn't work in an air gapped network with certain needed features (video chat is one). You do not want to know how much they ask per year for the on premise version (for greater than 10 users).
They are hardly shunned, just not preferred. Besides, I don't think Atlassian is interested in competing for heavy users that don't pay anything. They are pretty content with the enterprise IT market.
I hope they can learn from Trello to improve JIRA Agile. JIRA seems much better for software projects with organised sprints and large numbers of tickets, but front end performance is terrible and the overall UX feels like it could be improved significantly.
wow! I had recently decided to go all in on Trello for my personal use and I was in the process of making a Trello-Gitlab powerup (just like Trello Github powerup).
I wonder what the future of Trello is - both as a customer and as a software dev (I loved their remote work policy).
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 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.
...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.
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.
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.
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).
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.
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.
(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.
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.
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.
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.
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.
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.
> 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.
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.
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 :)
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.
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.
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.
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.
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.
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.
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.
> 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.
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
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'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).
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.
We're definitely investing in Gomix and we'll be revitalizing FogBugz this year, too — especially for folks who don't find Jira a satisfying or delightful way to work.
On a side note -- I don't know if they still do it (I believe they do), but Fog Creek used to give out free Fogbugz cloud accounts (2 user limit) to startups and students.
I've said it before and I've say it again: as a community we are not only poor at evaluating startup ideas but shockingly bad at appreciating actual business successes. You know the saying that hindsight is 20/20? Does not apply.
"I like Facebook, I use it often. $365B... for a message board. Yes, I use it. Yes, I think it is useful. Yes, I think this valuation is absolutely crazy."
Not many todo lists have millions of users, including some that pay actual money for the service. Having looked at many project management tools, Trello has absolutely nailed certain aspects of the user experience that many of the others get wrong. Try pasting an image into a card, for example.
It's not a perfect tool, but if you tried to recreate it yourself, you'd probably start to realize why they netted $450M.
There's a halo effect here. If Atlassian can drive powerful integrations with its current products then it can increase the value proposition for those products among Trello customers, driving sales for its own products. Not that there was anything to prevent them from making those integrations before, but now they can go to Trello customers directly and ask them, "hey did you know you can create a Confluence meeting notes document, create a bunch of action items during the meeting, turn them all into Trello cards with the click of a button, and see the real time status of all of them straight from the Confluence document?"
Not sure if I fully agree. The potential and momentum is there for Trello, they can very well grow their sales team and expand their product lines into multiple sectors with this acquisition.
I'm a big fan of Trello and Atlassian both. Personally speaking, if all they do is take away the crippling "add on" restrictions in Trello for solo users, this will be a huge win.
They need to get Teams right before they are attacking anything except the coffee maker. I hope they do get it right cos we use s4b at work. I really want them to make that a capable product so that i dont have to use a basket of products to get communications done: yammer, s4b, email, FTP, sharepoint, internal systems (that really just need a bot to chat with instead of a app UI),....and many others.
Just gave it a shot, and it seems pretty good. It does not have all the features, and scrolling is a but clunky, but one could always submit a PR, right? :)
We tested it out at my company, and for the most part, it worked pretty good. Very Trello-like, and overall just a simple / easy to use Kanban board. Though, we did have problems 'viewing' the details of a card. Depending on how much data was in the details, it could take around 5-8 seconds to load.
764 comments
[ 3.3 ms ] story [ 648 ms ] threadAnyway. Not sure why some people want to move away from Trello now. Is it that they don't want an identity connection between JIRA and Trello (SSO or similar)?
I had the same feeling of "oh well, what else can I use in the future" when I read this post.
[1] https://wekan.io/
We've have been exposed to JIRA through external suppliers and that has been enough to make him on his edges now.
Personally I don't think much will change, at least in the first year or so until the contracts of the original developers lapse and they can move on to new things.
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.
Guess which two products I use every day, and which two I avoid like the plague.
Nothing that keeps it above Github, but they always seem to maintain feature parity.
/not a bitbucket shill
//just don't like inaccurate comments.
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.
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.
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).
1. https://i.imgur.com/Av70r03.png
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...
https://github.com/torvalds/linux/commit/b0b9b3df27d100a975b...
syntax highlighting would be like this, where keywords, function calls, and variables are all different colors.
https://bitbucket.org/site/master/issues/2874/ability-to-sea...
That's incredible.
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
Well ;) https://twitter.com/sreuter/status/818614016801009664 ...
Disclaimer: I work at Atlassian.
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.
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.
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
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.
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.
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.
Not trying to start the classic hg vs git debate, just saying that it's great to have the option.
(hate it when companies do this)
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.
https://www.mercurial-scm.org/repo/hg/
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.
https://bitbucket.org/durin42/hg-git
Check our RhodeCode for Enterprise SCM tool that supports Mercurial too.
Nice and simple.
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.
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.
* 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.
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.
https://github.com/blog/2272-introducing-projects-for-organi...
edit: Yes right now there might not be an exact competitor but in a few years it could easily match everything Jira does.
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.
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.
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
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.
You might not view them as that, but they are, well were.
In the Innovator's Dilemma sense, absolutely.
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.
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.
http://www.cgchannel.com/2014/03/softimage-died-to-make-max-...
https://www.change.org/p/autodesk-save-softimage
http://web.archive.org/web/20140519212219/http://e-roja.com/...
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
What Git GUI do you prefer?
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.
Definitely my favourite client, and OSS to boot. I can't really think of much I'd want changed to improve it.
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.
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.
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.
We have quite some exciting features and additions on the roadmap!
In combination with GitUp, it's still a great tool, but it could need better QA so that even edge cases are solid.
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
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.
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.
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.
Ha, try using it in Linux!
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.
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?
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.
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.
https://news.ycombinator.com/item?id=11759733
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.
Here's the migration docs: https://github.com/wekan/wekan/wiki/Migrating-from-Trello
https://hn.algolia.com/?query=taiga.io&sort=byPopularity&pre...
Somehow the only good things I heared about them came from people who made their money by building stuff they wanted to sell on the Atlassian platform. People less biased always choose alternatives.
I can't say much about them myself. I only used Bitbucket, because of the free private repos. Their UIs are pretty mediocre, but I use it via Git cli, so it doesn't matter much for me.
After Atlassian bought them:
* The service I paid £5 a month for became free
* The stability issues started to improve in a dramatic fashion
Today Stash is a great product (IMO), and BitBucket has really improved from having great Jira integration.
I was actually sad because I couldn't justify paying for the premium features (multi-person private repos) in the same way, because it was nothing I needed. It was the best £5 subscription I ever had :)
I generally prefer Bitbucket over Github now (was a paid subscriber of Github). I basically use Bitbucket now for private repos and Github for my public repos, since Github does seem to be the place to put open source projects.
If my Bitbucket needs ever reach the point of having to pay for a subscription, I'll do it gladly.
We use Jira since the early days, and are quite pleased with them.
So far, all the other systems I have used were all worse than Jira.
JIRA has its quirks but it's very flexible and customisable. Its UX is also quite ok for such a complex piece of software. Keep in mind they're competing with stuff like SharePoint and downright UX atrocities such as HP ALM.
Confluence is among the best enterprise wikis targeting end users (i.e. users not familiar with Markdown), too.
They don't say if it will stay free or not.
[0] https://jira.atlassian.com/browse/JRA-1369
[1] https://jira.atlassian.com/browse/JRA-3821
PS: Here's a bonus issue that took 10 years to resolve (renaming users!): https://jira.atlassian.com/browse/JRA-1549
Not as old, only 5 years. Yet this is blocking my switch to a new CI server (GoCD) and makes building pull requests in general a pain.
Whining about a for-profit product no longer having a free-tier is odd to me. Either be fine paying for the service (nothing wrong with that) or pickup software that is free; I for instance personally use org-mode and Emacs heavily for all of my personal information management.
I also do not understand the sentiment that every product acquired will slowly begin to suck; that happens for some products sure but the converse is also the case.
To be fair to Atlassian, I used to hate Jira a lot but in recent years had to use it for work and it quickly grew on me; they are putting effort into improving their services / products, modernizing their software development processes and technologies, and delivering updates to their software on a regular basis.
If you're going to contribute here, please be more constructive or detailed. Why not talk about your ideas for a project that is free that anybody could install on their servers that does what Trello does if you do not like that they may begin charging for Trello?
Edit: fixed unintended mistake in the company name
Spark Calital and Index Ventures must have gotten a nice huge return, Trello only raised $10 million.
So I wonder if they are mostly aquiring the user base here in order to expand their potential market?
This acquisition makes total sense; Trello and JIRA target mostly non-overlapping market segments and there are some easy low-hanging integration fruits to be picked. I'll also bet Trello becomes a deal-sweetener going forward. License JIRA and for +15% you also get Trello for your whole company.
https://trello.com/b/gHooNW9I/ue4-roadmap
I know a lot of smaller dev teams use it for lowercase-a agile projects and I currently use it for all my personal projects. It's basically the antithesis of heavyweight tools like Jira.
What was your experience like?
I've yet to see a project manager or anyone outside hardcore development get anything positive out of at Asian products.
Their tools typically complicates everything to the point of slowing production by as much as 150% compared to projects where management is done with post it's on a board and physical meetings... I know because we did the business case, which today means we're actively avoiding companies that want to tunnel projects into things like JIRA.
I get that atlassian produce excellent tools for tracking development time so companies can bill me more precisely. Unfortunately the side effect is that everything gets produced slower, more expensively and ends up confusing the shit out of our project managers.
1. Create an awesome ToDo list
2. ???
3. Profit
1. Write really popular blog.
2. Create Stack overflow and make it the goto for developers.
3. Create todo list
etc..
The brand was there before they even started the todo list. All it took was a blog post "We are going to create a todo list now" and it was pretty much set.
From a strategic standpoint, selling Trello is probably a more favorable way for Spolsky and Pryor to raise $360 million in cash than through venture capital. In hindsight it's not implausible that the goal behind developing Trello was always to sell it off. Unlike StackOverflow, Trello has lots of competitors and it's value in is in integrating with the rest of a project's workflow. Essentially it's a commodity.
Restyaboard: http://restya.com/board (open source, self-hosted)
Phabricator Projects https://www.phacility.com/phabricator/projects/ (open source, self-hosted, or paid hosting)
Kanban: https://kanboard.net/ (open source, self-hosted, or paid hosting)
Wekan: https://wekan.io/ (open source, self-hosted)
And no doubt, lots more not listed here...
Then I remembered my difficulty with finding a proper to-do app. Yes, it will have millions of people make a clone, but it will also have thousands publishing crappy versions.
Bitbucket may still be less popular but I don't see it being shunned. That's what made me wonder. I wouldn't mind if you said that it was not given enough attention or even that it was being ignored (Although I'd still disagree). Maybe bad choice of words?
I wonder what the future of Trello is - both as a customer and as a software dev (I loved their remote work policy).
Hopefully Atlassian can learn from what makes Trello so wonderful instead of JIRA-ifying it into oblivion.
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 kill trello so everyone is stuck with JIRA. Someone please make a trello clone with reasonable pricing, now!
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.
Better tell the Wekan team they're wasting their time then. ;-)
https://wekan.io/
Big difference.
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.
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).
And yet, Hipchat is a bloated, unreliable mess.
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.
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.
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.
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.
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?
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.
Ehh...
If anyone here has ever been confused by the expression "damning with faint praise", I hope this is an illustrative example.
The "least-worst option" means it's not good, but all the alternatives are terrible. That's not damning.
> 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.
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.
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.
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 :)
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.
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.
https://wekan.io/
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.
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... :(
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).
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.
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.
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.
https://blogs.atlassian.com/2017/01/atlassian-plus-trello/
https://trello.com/pricing
Edit: I guess you mean these three blurbs? http://web.archive.org/web/20160505012250/https://trello.com...
Edit: I guess the spinning-out doesn't say anything about ownership (though the article does say Trello did a round of funding after the spin-out)
You get a live web editor + hosting and you can easily publish childish web apps ... uh MVPs.
Does anyone know or, better yet, use any good self-hosted Trello alternatives?
If you are to astroturf, at least show some diligence.
Not many todo lists have millions of users, including some that pay actual money for the service. Having looked at many project management tools, Trello has absolutely nailed certain aspects of the user experience that many of the others get wrong. Try pasting an image into a card, for example.
It's not a perfect tool, but if you tried to recreate it yourself, you'd probably start to realize why they netted $450M.
FB has 3 orders of magnitude more value than Trello with 2 orders of magnitude more users.
https://github.com/blog/2256-a-whole-new-github-universe-ann...