We have the technical know-how to administer data center versions of their products, but we can’t do shit if they force potential customers to pay for a minimum of 40 000 USD for a license per product.
Many of these orgs have multiple Atlassian products so this will probably end up doubling costs on several products at the same time effectively making it a money sink and impossible to justify to their budgeting.
I would have been perfectly OK with DC taking over server with similar pricing, but this is just a monumentally idiotic greed-driven move.
Now small-medium-large organizations are either forced to pay A LOT of money for self-hosting their highly protected data or either use their cloud. The latter is out of question for almost all of the organisations I know.
If I was a Microsoft or another enterprise tech company I’d hire a thousand engineers tomorrow to develop a Jira/Confluence competitor before the grace period for server licenses ends. All that engineering money will pay itself back whent they can sell modern collab tools without tech debt from 15 years ago for a price we can tolerate.
The split between cloud and server offerings is partly to blame here.
My thoughts go out to the businesses that have built plugins for Jira and had to endure the variances between cloud and server, or worse, only catered for the server market.
The group at tempo timesheets particularly come to mind here.
Thinking ahead - I’m hoping that an org like GitLab (who have got their Saas v On-Prem offerings balance right) is able to keep building on and catering for this space.
Their planning features are not there yet, but there’s a great group of people with oodles of traction and a roadmap that aligns with this problem space.
That's not really an option for organizations whose main product isn't code, no?
Azure DevOps Server, née Visual Studio Team System, already exists.
Congratulations, according to Google you are the first person on the internet ever to use that phrase. Indeed only the second ever to string the last four of those words together.
> There are two kinds of programming languages: the ones people complain about and the ones nobody uses.
JIRA is the C++ of project management software. It works. It has worked forever. It is easy to shoot yourself in the foot but a savvy operator can't be beat. It's unwieldy at first but gives you all the power to build a really sophisticated and efficient process.
I do know that getting put in the jira team is one of the least fun parts of working for atlassian.
Given the option, I will always push for Jira, and associated Atlassian products.
I think the reason you like it is exactly the reason a lot of people hate it.
JIRA in its default state is fairly sane. People who hate it, usually with a white-hot burning passion, really hate the ham-fisted customisations their own organisation has done to it.
Why has this had adds playing every time I turn my radio on for the last 2 years as well..?
I'm not the previous commenter, but I also have a similar 30+ years experience, and I've used quite a lot of project management software. I've seen Jira used poorly, and used quite efficiently for managing projects. My current job uses Jira and nobody in the company has ever expressed anything negative about Jira, and it's become quite nice to use. But again, I have seen some companies absolutely fail at Jira. YMMV.
I have seen some people fawning over tools like Asana but in my usage I just found it fancier and slower than Jira.
Personally, as a developer I find GitHub issues to be good enough.
I left that job and for awhile working at places using different ticketing systems, hearing complaints on places like HN about Jira, and wishing for features those other systems were missing. A few years ago I started at a place that used the cloud hosted Jira at a much smaller company (with an enthusiastic lead who likely tweaked the setup himself). It was a much, much worse experience. It was horribly slow and I guess they had focused on "management" features that made a normal ticket process annoying and confusing (it may have been how it was configured). Reading around I think the horrible performance was because of scaling architecture decisions that Atlassian made, which I heard they've at least acknowledged and are addressing. I gasped when I saw this headline they plan to drop local hosting before getting cloud performance issues behind them.
I wish we had something even half as good as Jira.
JIRA sucks, but it sucks compared to more lightweight tools and the modern aesthetic
It outperforms previous tracking tools like bugzilla, trac, or those proprietary piles of crap like the "Rational" tools
I've used JIRA at multiple workplaces and really enjoy it. I like Github issues and Trello for my personal task/issue tracking but I don't think they're suitable for more complex projects.
In this thread there's people saying that inability to host on prem is an absolute blocker for them, for others they have zero problems with their data being SaaS-hosted. Some people need deep analytics to measure how their team is doing and they can meet deliverables, and some people could care less. Some people have 10+ workflow stages with tons of rules, some people are fine with Todo / in progress / done.
If you have a small team and dont really care about reporting, Trello is probably a great option for you.
If you want reporting, but are willing to work with a somewhat prescribed workflow / process, across a few teams at most, clubhouse or pivotal tracker are great.
If you need full control and flexibility, and are willing to give up some ease of use and speed, JIRA probably is your best bet.
In the place I worked at with quality there was a multi page document on how to file a ticket. It was a nightmare.
This is just... wow.
Every Microsoft shop I've ever worked at defaults to Azure. You need a really good reason to use GCP or AWS for anything, and it's an uphill battle. They're already paying licensing fees to Microsoft, there are incentives and discounts to stay within the ecosystem. My current employer has GitHub Enterprise and we still use DevOps for a lot of stuff, especially anything that business stakeholders have to touch.
(1) Github Enterprise, the alternative suggested, is a Microsoft product (Github is Microsoft), not GCP or AWS. Given the way Microsoft seems to be investing and promoting products, seeing Github Enterprise as having more legs than Azure DevOps is completely reasonable. (And I'm the one who introduced Azure DevOps into the discussion.)
(2) I work for what has historically been an enterprise Microsoft shop; our cloud transition, except for some use of Github and Azure AD, been primarily AWS-based.
Same here for the MS shops I work with; actually no Azure at all.
If you talk to a Microsoft rep, they “recommend github enterprise for new projects”.
Microsoft obviously cares about backwards compatibility, and there is no way to currently migrate your stuff.
So... it’s not going to happen tomorrow, but it is going to happen.
...and no, it doesn’t have the nice clickops UI from devops: but that’s legacy now in favour of the multistage yaml pipelines.
You can close your eyes and cross your fingers and say Azure Devops will
Be around forever... but, you’d be wrong.
The amount of bugs i encountered is.. Bad. From not starting build agents, to stopped agents to hanging etc etc etc..
That said: i looooove the docker container concept for builders :)
I think this is on purpose to push people to the clould offering.
There's also an automatic import process from Jira .
YouTrack has a cloud version now. Unfortunately they used the introduction of this to raise the prices for their self-hosted version. However they do allow migration both to and from the cloud version, and they plan to introduce a self-hosted version of their newest Space product, so it seems JetBrains is more DIY friendly than Atlassian.
JB seem like a better company anyway. It's hard to forget Atlassian's decision to stop rewarding employees based on merit, a system they claimed was created by "white men" . The new system rewards employees largely for following the "company values". Under the company values page , they claim one of their values is "Don’t #@!% the customer". Interesting way to show it.
I've worked with confluence and jira and they are not as good as other products - but we can put any kind of confidential data in them. Everybody likes sharepoint/google docs/slack way better.
Looking for a Confluence competitor with permissions, version tracking, templates, and search but don't feel like I have found a good alternative.
We basically use confluence like a wiki, but it's abnormally hard to put info into it.
Me too. How awesome is that! Its absolutely fantastic news.
Edit: This is great for those of us that have to suffer Atlassian products that we didn't choose. It is also good news for companies such as Gitlab that do offer self-hosted solutions.
The split between cloud and server offerings is partly to blame here
The group at tempo timesheets particularly come to mind here
Gitlab is great for their developer niche, but the relatively weak issue tracker and wiki lets them down for more general use. Still, Gitlab is a great company with momentum and a roadmap. Feel free to join us  in looking at such alternatives.
"Relatively weak issue tracker and wiki" got me interested - mind elaborating in more detail what brings you to this conclusion? :)
You really don't know why Gitlab is not an issue tracker like Jira is? I'm sure you do, or at least you should know. Being an issue tracker like Jira is not even a bad thing! So why try to look like you think you can be as bad as Jira?
/rant (from a Gitlab fan)
sorry that it came around this way. I was really interested in your honest opinion, as my personal experience with Jira is limited at this point with 7 months into my new role. I have been asked about it during past GitLab trainings in my old job, but never used it in production myself. May sound weird, but I learn the most from users sharing their experiences :) Hence my question, it would help my research.
We're really larger than "medium-sized", but we're not the kind of company that can or will force everyone to use Jira.
Jira adoption could have happened, but it would only have been possible in a bottom-up, team-by-team basis. And certainly not with a $40000 starting price tag.
As it is, yeah, we're planning on migrating off Jira now.
Microsoft already has GitHub that works fine as a Jira/Confluence substitute for technical people. Maybe this will be their call to make it more accessable.
But if you want to replace Confluence as the knowledge base for the business people, there's Sharepoint, which is better than massaging your genitals with broken glass, but not by much.
So Atlassian is doing it because they know there is no competitor that would jump in. Because everyone else also goes that direction.
“Previously known as Team Foundation Server (TFS), Azure DevOps Server is a set of collaborative software development tools, hosted on-premises.”
New Confluence licenses will no longer be available in 2021 and support ends in 2024 (though it seems the Data Centre version will still be available, but it's expensive). That's potentially 3-4 years lead time to get something going. Either totally on-prem or an either-or option (à lab GitLab).
Not only is the product being killed, they're raising the price during the migration period. Their FAQ also hints that even more price increases are coming. I imagine they'll lose a lot of customers that can't or won't send all of their data into the cloud
So they need to focus their developers onto building features on the Cloud product codebase, but I am not hopeful that this means they'll actually ship features faster.
In fact, it gets tricky as you have "location-flagged" functionality depending upon Cloud or Self-hosted.
We did this from scratch @ Documize by making (bold?) choices around deployment/runtime and database schema design for both SaaS and self-hosted "products":
- run the exact same binary (we used Golang)
- share/use the exact same database schema
- data migration process the same for schema changes
- support multi-tenanting: "enterprise" self-hosted also multi-tenanting so different teams/departments internally get different URLs
- use the same "build" process to compile and ship
Probably plenty more I could tell you!
Despite that, it feels very slow. Not the occasional 10+ second page load, where you've accidentally clicked something that happens to generate a cascade of cache misses. I can forgive that kind of infrequent performance hiccup.
But rather, regular usage, especially of Confluence and Jira, just feels sluggish when doing bread and butter actions - adding a comment to a ticket or reloading a kanban view, loading a new page or opening the search dialog on Confluence.
Yet, everything I've heard about the responsiveness of the 'cloud' offering is that it drives people to move to the on-prem server version.
It's hard for me to imagine that atlassian would allow individual instances of jira/confluence/etc in their cloud versions to get nearly as much resources as you need to give them on-prem. The incentive would always be for them to try to minimize the amount of memory every instance gets, which does NOT maximize your individual performance. Shared resources will also make performance more variable and "noisy", making it more difficult to narrow down specific causes. It's hard for me to see how "Java" and "cloud" go together.
AirBnb, LinkedIn, Netflix, Twitter, Foursquare, Sony, Shopify etc.
Most of the top tier websites use something on the JVM e.g. Java, Scala.
I always wondered that, too! Like, you'd think that if you have devs building a product and a team running a hosted instance of the product in the same company, that they'd have a very good feedback loop and make it easy to run the thing and to do it well. Although, I wonder if the answer is that it's not the same product - like with bitbucket, where the thing they run in the cloud isn't the same thing as they sell for on-prem. Or even a lighter version (BB, AFAIK, is literally 2 separate codebases), where they cut features in order to make the cloud version work.
> It's hard for me to see how "Java" and "cloud" go together.
Nah, it's not Java, it's the specific product. I've worked at a SaaS shop that did all Java, and while the pathological cases are comically bad, it's actually fine most of the time IME.
They forked the code base around 5 years ago now. Cloud/on prem.
Cloud is or was multi tenanted, you didn’t get your own isolated server, you got routed to some compute that would then pull data at request time based on your tenant id.
With a hard fork of two seperate product streams it was inevitable at some point maintaining feature parity between products would get to much.
Java and cloud go together quite nicely. Backend services, a JVM that has now be tuned for many many years by lots of clever people. If you have a long lived service it works really well. It works better than your node js app running a single instance on a multi core server with the event loop getting blocked.
The amount of effort I would fathom needed to maintain a single code base that's architected to do both would be exhausting.
I'm disappointed they don't just come out and say it, i.e. play open cards and help your customers understand
The homedir for our on-prem Confluence instance is >120GB and the MySQL dump is 26GB uncompressed (2GB gzipped).
Not sure how that import would/will go.
> It's hard for me to imagine that atlassian would allow individual instances of jira/confluence/etc in their cloud versions to get nearly as much resources as you need to give them on-prem
Yes, which is why the atlasaian cloud is no longer a collection of individual customer instances. More details: https://youtu.be/0N4KknY_zdU
Why? From its release, Java has been used for SaaS. SAP runs its cloud services using Java and this includes subsidiaries Ariba, Concur, and SuccessFactors.
Given the number of companies known to use Java in the cloud very successfully, this is a “Citation Needed” moment.
Oh and they keep updating the UI which involves shuffling things around and every new version is slower than the last. If you're running on-prem you at least get to decide when to update and notify everyone accordingly. We'd just find out one day that everything has been moved around and learn the new locations of different features.
Sorry I'm really just generally ranting about Jira now but honestly I find it so infuriating to use. Confluence as well, how did they manage to make wikis suck so bad?
I use Confluence regularly over a high latency (600ms) link - and this has the surprise / delayed page load you describe, with the newer search features refusing to action your search request until it's loaded & rendered a large overlay on the right-hand side of the screen.
These two attributes make are hugely frustrating, given looking for information is the key function of a wiki.
It is not a particular area it is the whole thing. Every interaction makes me want to gouge my own eyes out. It's a glorified text area with a menu, why should every click cause dozens of requests that take more than 10 seconds to complete?
I can only conclude Atlassian engineering is utterly disfunctional for this to have gone on so long unimproved.
We definitely recognize we have a lot of work to do on performance in general, and we're definitely trying. "fixing everything" is definitely part of our plans, but we'd also like to "fix whatever users find the most frustrating".
If any specific items stand out as the most frustrating please do let us know.
Pressing refresh on the front page causes TWO HUNDRED AND SIXTEEN requests for about 7MB of resources.
The only meaningful content on this page is a list of 20 or so links.
You don't need customer feedback here, you need some basic engineering principles and a tiny bit of pride.
Thank you for the insight. We are definitely working on generalized efforts to make 'most/all/everything' faster (including speeding up the app overhead), but those types of projects unsurprisingly take a little longer to finish.
On the other hand, specific user feedback might be 'the most annoying thing to me is that pages with Links load slowly, I need the links to load earlier because of X', or 'I need inline comments to load faster than page comments, because of reason Y'
-> this type of feedback could give us something we can fix quickly and alleviate user frustration sooner. Hopefully the intention makes sense.
Of course, in general, we're also always looking for any feedback that can help us improve Confluence!
Thanks for the consideration - we are working on big fixes as well, but can't share information about those until we are closer to shipping. In the mean time we're open to suggestions and feedback of all types.
My original post did not mean to give the impression we think Confluence is fast - we do recognize that we have a lot of room for improvement.
The reason we're asking for feedback on specific areas that are annoying is that while we can work on making 'everything' faster, knowing which specific items may be of the most concern may allow us to focus fix those items first.
If you do have any feedback around such specific items we would be happy if you're willing to share it.
We have a lot of metrics, and we recognize that Confluence is not as fast or as good an experience as it should be.
However nothing beats user feedback - hearing specific feedback from users may provide us with specific areas that we can focus our work, on top of the work we're already doing.
If you have any feedback like that, we're hopeful you're willing to share it with us.
I've heard the same about cloud performance, which seems to be an argument against it being simply configuration, but who really knows?
Confluence just sucks though.
2. Editing is a clunky process. Not only is the UX subpar, it never loads all the possible widgets you can insert, making dynamic content a pain.
3. Awful search. It always manages to find internal process documents from 2014 and not the service pages I actually want.
4. Tough to reorganize content. Moving a page around is just hard enough that people tend not to do it, resulting in really poorly organized content.
Honestly, I’d be happier using notion or just GitHub wikis. But the main benefit of putting our docs at wiki.$COMPANY.com is that I can guarantee discoverability for other teams, so we’re kinda stuck with it.
* It's really hard to scale support. You end up being on the hook for why "it's not working" in thousands of different of environments you have zero control over. Anyone qualified to do that level of support could be making more money not hating their life.
* Nobody wants to pay for updates. I mean it's totally rational but we also don't want to support $old_version forever.
* Even when updates were free people still didn't do it. Telling your users "sorry you're using an ancient version, please update" just makes people angry. Again, understandable, but surprise! those same people suddenly weren't angry about updates once they were on our SaaS offering. Turns out that frog boiling is reasonably effective.
* We had to deal with swaths of customer complaints about performance that we're mostly not our fault. Sorry our app is slow on 1/64th of a used SuperMicro. Maybe your IT department should get on GoFundMe?
I get that telling customers this kind of thing is hard, but sometimes it just has to be done.
I think this is a fundamental issue with the software world: there aren't enough skilled sysadmins left anymore (how many people even call themselves sysadmins these days), so the more options users have the more ways to get things wrong they'll find. The vague, open ended nature of "support" means it ends up being an unsatisfactory experience. When the only people who need support are the in-house devops team, it's a lot easier.
Unfortunately there don't seem to be good solutions for this. If users aren't given choices, they may leave or never turn up at all, but once that pain is over they won't be unhappy again (unless you have a major outage). Give them choices and when things blow up they'll become an angry unhappy customer with a support contract, which is every businesses worst nightmare.
I think telling people we support version x - y and facing a problem say try upgrading makes people angry
Telling people we support version a - b and sorting out their issue is fine even when a-b is smaller than x-y
I know support have it difficult because no one can be across all the bugs, regression and fixes, for multiple versions/configurations
Even though most of things the users complained about would have been fixed with upgrades.
- Customer must start with cloud,
- Data Center is the overweight offering, starts with thousands of users, grossly overpriced like GitHub Enterprise.
It's an difficult position Atlassian are inflicting on tens of thousands of customers. Atlassian's self-hosted products are uniquely flexible, being built on a plugin architecture, and many orgs have indeed customized Jira extensively with plugins, notably ScriptRunner . Atlassian's Cloud plugins have their APIs, but have nothing like the same flexibility. A lot of functionality just isn't possible in the Cloud architecture. It's a bit like Firefox moving from XUL to an extension API.
In my opinion, the most customer-respecting way forward would be for Atlassian to open-source their discontinued Server product line. Go to the "open core" model with the clustered Data Center product as the upsell. This avoids screwing over their customers, and if their Cloud product really is as good as they say, customers will migrate to it naturally over time. It's the kind of damn-the-torpedoes move I think Mike CB would like.
But over the next 3 years, lots of painful migrating or evaluating-of-alternatives will need to happen, and perhaps a non-Atlassian forum for sharing experiences will help.
little did you know, the source code for atlassian server products is already available for any paying customers. It's not FOSS, but if you need to run this yourself, and customize it, it's already possible. But of course, you will be responsible for keeping it updated (patching vulnerabilities from libraries etc).
The other advantage of the JB approach is it's one click install and upgrade. No schema migrations, complicated issues with DBA hoarding permissions etc.
A lot of what makes Jira so broken is that it is way too flexible, and this flexibility has costs in terms of performance and stability. There’s a damn good reason why I used Chrome back in the XUL days for FF; because XUL FF was not performant or stable for me back then.
Sharepoint is god awful for anything Confluence is good at - namely being a wiki aimed at technical documentation. OneNote is a little better but even the online OneNote isn't great great, and both are a few steps backward in functionality.
At least they if we mess up security on a host inside our business it’s not the end of the world.
edit: I don’t make the money decisions here, I am just a peon.
Banks are still in the stone age when it comes to NIST and cyber security.
For example, if my employer (for whom the use of cloud hosted service is simply not possible) wanted to keep using Atlassian products, moving to datacenter would cost us many thousands of dollars more per year in maintenance while wasting literally hundreds of unnecessary seats we'd be forced to pay for.
This announcement has ruined my day. Not only will we have to abandon a number of projects to implement new Atlassian products, we'll have to start planning to migrate all of our existing instances to other products and re-build all the work flow and customisations in those. At least they've given a few years window for changeover, but this is going to generate a lot of work and our confluence power-users are going to be very upset at having to move to Sharepoint or some other horror.
Server products is what made us purchase Atlassian software. There are numerous reasons why our company (and a lot of other companies I presume) would like to avoid cloud. And if we really had to go cloud, I simply don't see why we would choose Atlassian over alternatives.
For Bamboo, I immediately think of Jenkins, although it's showing its age now.
For Confluence, I think of Media Wiki.
For BitBucket, I think of self-hosted GitLab.
Not sure about Jira or Service Desk, though.
I'd appreciate any better suggestions.
The thing Atlassian had going for them is that we could get our non-technical people to use their stuff, understand it, and even customize it themselves to meet their needs. I'm not looking forward to trying to bend some other issue-tracking system to do it, so I'm guessing we'll pony up for the DC-class charges (for the few years they continue offering that option) and see if a competitor emerges.
The thing Atlassian had going for them is that we could get our non-technical people to use their stuff, understand it, and even customize it themselves to meet their needs.
Confluence is probably the hardest one. You could use any wiki software but the new "live-editing" stuff (Google Docs style) is pretty good for productivity. Hard to find an on-prem equivalent. Confluence's integration with Jira is hard to compare too.
I always go the impression that GitLab was doing excellent in code related workloads but sub-par in issue and test record tracking.
Tuleap shines with very advanced tracking capabilities and, most important, empower end users to manage it. Unlike Jira, you don't depend on a central admin to tweak you configuration, everything is at hand.
Git & CI capabilities are built-in but if you prefer gitlab for that, you will have soon an integration between the 2 tools. It's part of the next delivery  due mid november.
- federated file sharing
- real-time collaboration (e.g. via OnlyOffice or Collabora)
- video conferencing
- webhooks and push notifications
- discussions and mailing lists via Discourse
- Matrix/Element, Mattermost, or Rocket.Chat, IRC, and Slack integration
- Github and GitLab integration
- help desk via Zammand
Nextcloud is not without shortcomings. But, it's strengths are being federated, open-source, and integrated with an exosystem of open-source community and productivity tools.
One additional note, our small cooperative uses a managed version of Nextcloud from Web Hosting. The cost starts at $35/month for fully managed or $7/month to update Nextcloud manually via the settings page (which is surprisingly simple). The Web Hosting Web page and sign-up process are slightly klunky, but their customer care has been excellent in my experience.
Your FAQ also says to "Contact [You]" regarding on-prem instead of pointing to the GitHub, which imo conceals the fact that you can build and run it without a restrictive license.
Its fast, lightweight and MIT licensed.
Rather opinionated in design and structure though.
Some big organizations are using it (like Facebook, Wikimedia Foundation, Mozilla)
Does anyone have a first hand experience working with it comparing to standard Atlassian stack?
(It's my start-up.)
Having used and looked inside both Media Wiki and its enterprise fork BlueSpice, I can't really recommend either if you need anything more serious than just "minimum viable wiki features".
A few years back we temporarily switched from using Confluence to Xwiki, which worked okay for a while, but then different small and medium issues kept adding up until we had to go back to Confluence and swallow the increased price (sixfold in a span of 3 or so years). This was with Xwiki 8 though, the current version 12 might have improved things, I should try it again really.
(Disclaimer: I'm from the dev team)
Disclaimer, I am CEO
Atlassian feels like a bunch of individually purchased products that they then just jam together with integrations that never quite work the way they should.
I wish my company would abandon it.
To be slightly more charitable, this is a sensible move as at least this way Atlassian can control the end user experience and (perhaps!) have it not be utter trash. Far easier for them to manage this way.
One thing I like about the server versions is the ability to spin up development versions of these applications so I can test out new plugins, version updates, or complicated configuration changes without affecting our production applications.
So much for that. I guess I can skip that step and when it goes wrong in production I can be the old man who yells at "the cloud".
If only they made the DC cheaper I wouldn’t be so disappointed.
I'm using it for ages now and i have not seen any real features being added in the last 10 years and fundamental issues have not been adressed.
The weirdest thing was their UI change a few years back where they thought it would be great to make core workflows 1 or 2 clicks further away than before.
Like 'creating a ticket; went behind this plus button thing.
Plenty of features i would love to see, the community votes them up as well but nothing happens.
Apparently they are to busy with stuff no one is seeing. Hope that actually brings in innovation.
Then there's fossil[^2], which is brilliant, and is completely self-contained, with version controlling, wiki, etc. It's a bit awkward, but nonetheless feature full.
It would be nice if Atlassian open-sourced Bamboo so that we could continue using it long-term, but honestly one of the primary reasons that we’ve stuck with them is their excellent support team. Without them, our development team would be forced to diagnose and fix issues in Bamboo, which is not the best use of dev time. So I guess we’ll attempt to find alternative build software soon.
Our biggest complaint about Atlassian has always been the constantly rising price while value does not follow, and this might finally make them too expensive that we would be better served by alternatives, especially considering all the re-integration we would have to do in any case.
We do still use Jira Cloud but while the UI and search is better the performance is just awful.
Note that they do have a good vscode extension that integrates well with the development workflow, creating branches for tickets, commenting and so on. I use it to see issues, get notifications in vscode for new bugs and transition issues. It's good for viewing basic text but poor for media rich content.
I also use the go-jira unofficial cli tool written in golang which is just a joy to configure and use. It supports a templating system for creating new issues and custom commands to do all kinds of tasks.
Paired with GitHub Issues and PRs vscode extension, this enables me to work in the text editor most of the time.
If we’d bought Bamboo a month ago, I’d be ready to develop a temper.
That honestly sounds like an oxymoron.
On the other hand, this is great for me because I pretty much hate using all of these products. If this gets my company to stop using them, I will be so happy.
What specifically sucks about Jira and Confluence?
I don't use Jira as much, but as far as I can tell, everything that comes out of Jira is incomprehensible. I get lots of emails from its CI system, and they never have any useful information. It might indicate that a build failed or some warning was present, but it doesn't say what in the email, and there's no link I can click on to take me right to the logs. I mean there's a link, and it shows me something that looks like a log, but I can't find the actual parts where it built our product or what the errors or warnings were. It's basically just a web page of terminal output. No formatting to make it more readable, etc. Why not just send me the log if you're not even going to format it? It's so bizarre.
On the one hand, I’m glad Atlassian has finally come clean on what’s obviously been their strategy for some time. On the other hand, it kinda sucks for customers like us. Yes, we’re a big company and yes, we run data center instances of some of the tools. But we’ve also got tons of smaller instances running around that basically have nowhere to go now. There are several industries that are incline to stay on premise: healthcare, legal, and financial software among others. We’re in that same boat.
At the moment, I’m inclined to recommend we drop Atlassian altogether, for several reasons:
First, Atlassian has never really understood the needs of large enterprises. They’ve recognized that we need performance and scalability and top level web security, but the rest of our large enterprise requiements remain largely unmet.
Secondly, I haven’t seen any good organic development from Atlassian for a long time. They’ve bought a lot of other products and companies, but their ability to produce and deliver great features disappeared a long time ago.
Finally, I have no confidence that Atlassian will keep the data center products going and properly maintain them. Something tells me they’ll do what’s necessary to keep too many customers from immediately jumping ship, but in the long run, I expect we’ll eventually see the end of life for the data center products just like they’ve done with the server products.
What are some the unmet requirements?
Also: email handling sucks and support for the scaled agile model is pretty non-existent.
Just in general though, take a look at jira.atlassian.com and see all the issues with thousands of votes that have been unresolved for years and years.
Jira is ok, it can be slow. Confluence seems to be playing catch-up with notion.
If I were to start a startup, I'd probably avoid atlassian.
This is a step in the same direction.
I wonder what institutions with a security restriction will do though.
Market opportunity for some rival?
You get the customization to yet another level as you are not constraint by the fact that templates are shared across your organization. You can tweak and customize every single tracker (issue type) with it's own fields & values without impacting others and without depending on an admin for that. You can deep dive with https://blog.tuleap.org/tuleap-versus-jira-software/
Try looking here:
We were using it up until a while ago (edit: oh, did the math, 7 years ago)... could still totally get by with it.
I keep my free Jira/Cloud account going, but when I look elsewhere, I don't really love the options either (Clubhouse, looking at you).
I decommissioned it last year (hint: there's a long and painful migration story here). Users and documents have migrated to Sphinx, that's been actively used for the past 10 years and was always supposed to replace trac (hint: there's a longer story on how to handle or not handle a migration here). It looks really good but the markup and editing tool is not really user friendly.
A few teams decided to move to the internal confluence instead, that's supposed to be the strategic solution in the company. Looks like they're up for another migration within 3 years.