We should celebrate their success because its events like this that create the motivation for some of us to go create something that "stands on their shoulders" or competes with them or creates some new paradigm of how tasks can be managed. Fog Creek is almost the ultimate startup - they keep it small, do things right, stick to their craft. What is the result? Regularly bring fantastic products to the world. Anybody contemplating how to get setup and run a software startup should start by reading most/all of joelonsoftware and then the later blogs about SO and Trello.
Yes Im huge fan - because i applaud geeks that put heart and soul into their craft as well as running their business and getting great outcomes like this. Would love to see more of it.
Not just JIRA; I think a lot of people were burnt by Atlassian's management of Hipchat or Bitbucket too.
Historically there's something of a track record where Atlassian is the place where interesting, innovative products go to stagnate. Bug fixes happen glacially (a 1 year turnaround seems to be standard), and new feature development doesn't happen at all. Running Hipchat is like looking through a window back at 2012.
> Very happy for the folks at Trello. Great outcome for a great tool.
Great outcome for a great team? Perhaps. But I don't really see how this benefits the tool, nor the people who use the tool, because I (and a lot of other people here) are assuming, with reason, that this deal heralds the end of further development of Trello.
If Bitbucket was not bought by Atlassian, it will be able to grow and compete with Github/Gitlab?
If Hipchat was not bought by Atlassian, it will be a serious contender for Slack?
Or perhaps the group behind those products reflected their growth today?
Do you think it is because Atlassian's management or because local's management? Say if Atlassian hold to their words: "we leave them alone".
Or perhaps the issue is Money+Motivation than anything else? Exit => rich => decrease in Drive.
We can debate counterfactuals all day, but the potential was absolutely there. Consider:
Hipchat was purchased by Atlassian before Slack even launched. (Slack launched August 2013; Hipchat purchased March 2012.) And back in 2012 Hipchat was almost exactly what it is today: A functional chat app with searchable logs, native clients for many platforms, a somewhat clunky UI, and some persistent issues with syncing and reliability. Further, when Slack launched, it wasn't nearly as good as it is now: They've made significant improvements over the years. Back in 2013 the Hipchat/Slack race was still pretty close, and that's after Hipchat had spent the last year doing nothing.
Slack launched into an opening that Hipchat created by stagnating. It's not that Hipchat could have potentially competed with Slack; it's that Hipchat could have easily crushed Slack. Slack exists now because they built the stuff that Hipchat didn't.
Have we ever looked the discussion from a different perspective?
This is fact: Atlassian tend to leave the acquired product alone.
This is question: These products that Atlassian left alone, why are they not growing according to (_yours_ assumed) potential? Have we ever asked that perhaps the people behind Hipchat maxed out their potential? Or perhaps the drive is not there anymore?
What I'm asking is this: Did Atlassian do something destructive after they acquire the company? or perhaps the acquired company just simply can't live up to their potential (for any reasons except Atlassian pushing their management to the acquired company).
It can't compete now anyway.
> If Hipchat was not bought by Atlassian, it will be a serious contender for Slack?
Hipchat is not even close to being a serious contender for Slack.
"Startup" is a nebulous term with no firm definition, so these kinds of arguments are bound to happen. Some people still say Facebook is a "startup" because it has the fast-paced environment with the normal superficial cultural trappings of a tech startup (food perks, no dress code, casual interpersonal culture, etc. etc.).
Ultimately it's probably just a dumb semantic argument that's best avoided.
My simple personal guide is: when it has been around for more than 2 years, has found a viable business strategy or is certain to be around for 4 more years.
There is a discussion on this question here:
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.
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.
Ha, try using it in Linux!
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.
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.
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.
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
git init --bare name_of_directory
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.
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.
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.
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.
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.
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.
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.
Not trying to start the classic hg vs git debate, just saying that it's great to have the option.
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.
(hate it when companies do this)
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.
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.
* Merge checks
* Build status (finally...)
* Audit logs
* Inline editing
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).
syntax highlighting would be like this, where keywords, function calls, and variables are all different colors.
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.
If you've got some wizardry working that isn't an external script, hook it up.
We've added 4 big features just in the last 12 months
+ 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
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.
With GitLab, one of our goals is to put all the pieces together. We are building out the integrations, step by step, from idea to production. We believe in a world where everyone can contribute to projects. In a large organization, this means diversity in workflows and individuals. Again, I mention that we are focused on really understanding who those users are as part of this exercise. Our UX design team has begun that work and we have already started research on personas. This will further drive our development of GitLab and make sure to nail those other use cases beyond the narrow scope of software development, into allowing companies to leverage GitLab to create software and processes to run their businesses.
In particular, here at GitLab we use GitLab itself for some HR operations too. So we recognize the potential there. And we even want to ship a simple feature for operational support tickets (https://gitlab.com/gitlab-org/gitlab-ee/issues/149). So we definitely recognize the breadth of opportunity and the gaps we still have.
Thanks for bringing up this very relevant discussion. We definitely recognize the shortcomings and we are working hard to improve in these areas. GitLab started out as a software management tool, similar to what you describe. But we are definitely looking to expand in multiple directions. One of them is definitely to make it a tool that is useful beyond just engineers. One of our major thrusts in this area is issue boards. We are considering who the individuals are in a large enterprise that would be interested in issue boards. And we can't solve every use case right away. So we are starting with personas like engineering managers, product managers, and designers. These are folks that may not be very technical, but still are important in the product development flow in a large organization. See this as an example: https://gitlab.com/gitlab-org/gitlab-ce/issues/24686
We definitely have our eye to expand beyond these use cases. So we anticipate getting into areas like road mapping, Gantt charts / swim lanes, etc. But again, we work iteratively at GitLab, so our very first stab in this area is burn down charts to get feedback on how a software iteration is performing. And then we build on that to bigger scopes like roadmaps for business managers, etc. See https://gitlab.com/gitlab-org/gitlab-ee/issues/91 for burn down charts.
In addition, we recognize the rich nature of teams and the multi-faceted of different roles in an organization. For lack of better term, we've called it "team-centered collaboration" in this issue, we start the discussion that we want to go beyond just software-first projects:
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.
Well ;) https://twitter.com/sreuter/status/818614016801009664 ...
Disclaimer: I work at Atlassian.
Guess which two products I use every day, and which two I avoid like the plague.
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.
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.
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.
1. Trello was smart in only taking $10M in VC funding . This allows for a 40x return for it's investors. If Trello were like many other startups, they probably would have taken too much VC money and got themselves in a situation where the VC wouldn't sell unless it was $2B+.
2. Atlassian now has a product that is loved by many developers and business people alike. It will easily be interegrated into their existing stack and it complements their products very well.
TLDR: Both Trello & Atlassian were smart in this acquisition. Couldn't be happier for them (and as a user).
Trello wasn't "smart" for only taking $10M in funding (and only in one, late, round, which means it only gave away probably 20-30% equity.)
Trello happened to be spun off from an established company, which took care of financing initial product development and growth. This is equivalent to the founders financing maybe a $1.5M round and a $4M round from their own pocket.
Don't try to beat Trello's benchmark in funding strategy, unless you happen to be able to finance the first few rounds from your own pocket.
> 2. Atlassian now has a product that [.] will easily be interegrated into their existing stack and it complements their products very well.
Atlassian would be wise to keep this integration from being too tight. Trello shines as the most general project management tool out there (except maybe a spreadsheet, although that is the one thing I can't bear to do with a spreadsheet), and if it became a developer-centric collaboration tool I for one would probably stop using it, even for collaboration among developers.
Will it? i use both Bitbucket and Jira at work, and i'm constantly finding myself wondering how two products from the same org can work so poorly together. They use their products to market their other products, but as far as actually integrating things into a seamless experience it doesn't seem like that's atlassian's strength.
In many ways that will be a good thing though, trello will likely remain trello instead of becoming something else to fit atlassian's ecosystem.
I suspect Atlassian could easily create some Jira/Botbucket addons that would make Jira a very useful choice for some Trello users for a more structured backend.
Trello are an amazing team and an amazing product, and what makes the product so amazing is how domain-agnostic it is. They refuse at all costs to add any feature that helps use Trello in one specific way over others (e.g. lists = stages in task lifetime, cards = tasks; lists = assigned people, cards = tasks; lists = dates, cards = events, ...), and that made Trello equally useful as a Kanban board, a CRM, or for a beer microbrewery tracking its different barrels and the stages of brewing they are at. The best thing about Trello is when you start organizing your board one way, then organically drift towards a more natural way to organize them, sometimes without noticing as you do. Trello is for processes that you're not sure yet about the right way to manage.
Atlassian is all about development team collaboration. Trello can be used for that, but not anymore than it can be used for brewing beer. Trello shines when you don't know in advance how you will want to manage a project. If Trello became a dev collaboratin tool, I would stop using it for dev collaboration because there are better specialized solutions for that. Keep Trello general. Please.
I promise you Atlassian understands why Trello is so successful. You described Trello's core strength perfectly - and this one of the reasons they are committed to keeping it as a standalone service.
(disclaimer: I'm the CEO of Trello)
In meeting with Michael, and discussing how we could work together, Michael could not be more clear that Trello's success is predicated on is breadth and its appeal to many different use-cases.
This is most clearly displayed in their inspiration page, that includes many, many use-cases:
This goes right to the core of all of the issues/conflicts bundled into this acquisition from UX details up through to target users and culture clash.
Time tracking is a manager-oriented feature, not a producer-oriented feature. The users producing the work usually resent things like fine grained time tracking and comparitive producer reporting because it distracts from actual work, treats creative or complex processes as though they are part of an assembly line, encourages micro-management, pits quality against time, and emphasizes wage servitude.
Managers can use Trello to stress out their employees too, but not to the extent that JIRA-ish tools enable.
The problem is you are selling to managers who love to micromanage their employees and have nothing better to do than fiddle with configuration, reports, or have meetings with the people they hired to do that.
This is why developers who are smart will probably try to protect themselves by pre-emptively replacing Trello with one of the dozens of free or inexpensive clones before you can start corporatizing it and their company.
I obviously have no idea how Trello is structured and whether Michael has any real ownership or not, given its unique history, but in the case of most SaaS founders, when their golden handcuffs expire, they call in rich, because duh, why wouldn't they? Especially after watching the bureaucracy at the acquirer kill their baby.
Why, you ask? As a recently public company Atlassian knows it'll need to grow beyond developers if they want to continue growing at a healthy rate, and Trello offers that exactly. I believe that's why they paid such a hefty price for it.
It just wouldn't make sense to throw away all those users...
Why is that? Why does a company that is good at something NEED to expand beyond their area of expertise? Is is just me who sees this as American Capitalism™? Wouldn't it be better to try to make their products excellent and attract the many developers who are not using their suite? Why the always constant push to grow at any cost?
I'm saying this as someone who has been using Atlassian products for a while. They seem to focus on JIRA and Confluence only, and letting all the other products be 2nd or even 3rd class citizens. Why expand if you cannot keep the software that you already own up to date?
Because you can as and because there are big rewards for doing it right and you're in a good position to that.
It's true for any company, and even more true for tech companies. They have to continue to grow for many reasons, including keeping their existing products better.
I personally am not a JIRA fan. We used it for a while and it just really didn't work out for us. The entire experience was too cumbersome and unfriendly. However, that has nothing to do with them growing. If anything, they're doing an amazing job growing with a product that isn't fun to use at all.
I disagree with this completely. Atlassian is in the business of collaboration tools. They've done that for developers, but it doesn't mean they're only capable of making developer tools.
Also, where's the risk here? Other than the inflated price I don't see any risk. Trello isn't just an idea but rather a real product with a massive team and a ton of users who love it. They've iterated on their platform enough so I imagine many of both the technical and experience aspects are polished enough. What am I missing?
On the bright side, this might pave the way for a new product in this space, or some open-source tools which replicate the same basic funtionality.
Those features should take at most a month and cost at most $25k to build.
Yes there are other things that make Trello stand out but I don't see a justification for this purchase if not just to hire the team.
Hopefully Atlassian can learn from what makes Trello so wonderful instead of JIRA-ifying it into oblivion.
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.
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 :)
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.
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.
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.
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.
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.
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.
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!
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).
Better tell the Wekan team they're wasting their time then. ;-)
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.
And yet, Hipchat is a bloated, unreliable mess.
Edit: I guess you mean these three blurbs? http://web.archive.org/web/20160505012250/https://trello.com...