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.
Wow. This must feel like a huge fuck-you to people that migrated to Atlassian because they could host things locally (I worked at a place that made the leap 3 years ago and it was a somewhat controversial decision. I feel kinda bad for everyone that'll be hearing an "I told you so" on Monday morning).
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
We're using Jira, Confluence, and BitBucket on-prem at our DC now, on some pretty sizeable VM's with good network connectivity back to head office.
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.
I don’t share the same experiences with slowness (maybe we do something right on the instances we manage). I do however experience slowness in cloud. I assume they increase cloud resources in some kinds of steps that make them appear extremely sluggish.
Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as:
- Pages with content X are the slowest
- Trying to do A/B/C is annoyingly slow
- etc
?
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 agree with you on user feedback being valuable, but not to figure out what's slow. You should be getting that information accurately through metrics and know what to prioritise without having to speak to anyone. Reserve questions you can't get answers for otherwise for user interviews.
You should be able to experience the slowness for yourself by spending a few minutes using your product. Then try something like notion or pretty much any other web app and notice how your blood pressure drops and your stress levels decrease.
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.
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!
Your response seems to show the problem. Trying to add little quick fixes might sound reasonable from a business perspective, but it's not going to help on the tech side. If anything it's going to make matters worse.
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.
Where is the data hosted? Somehow it feels like the devs are located close to the data and don't notice the lag. And for me in central Europe, some requests must travel across the world and back.
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.
While we had very similar experiences - only used JIRA but the performance was borderline-unusable - I've heard reputable sources say that configuration plays a tremendous role in that. I'm inclined to believe we just hadn't configured it "correctly," but the fact that you can destroy performance by casual misconfiguration is itself a pretty big issue.
I've heard the same about cloud performance, which seems to be an argument against it being simply configuration, but who really knows?
When I used JIRA Cloud about a year ago I measured 30s+ load times on every single page. For a nearly-empty instance with no customizations, just their scrum template.
The performance on the cloud version is awful. When I previously self hosted it was a miserable management experience, but it definitely felt snappier than the current cloud version does.
Atlassian does not provide particularly good guidance on how to get their tools to perform well. The first big issue for any moderately busy system is that you need to dedicate huge gobs of heap memory (think 16G+) to the tool. After that, they suffer from poor schema design - there are tables that are literally missing indexes on commonly queried columns, and some columns that have delimited values embedded in them.
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.
> 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.
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.
> 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 homedir for our on-prem Confluence instance is >120GB and the MySQL dump is 26GB uncompressed (2GB gzipped).
If Atlassian gets paid by month to store it, it seems ok. Most images seem to be in AWS anyway, so they probably don’t back them up. The DB can get big but is that a problem if they are paid to maintain it?
>It's hard for me to see how "Java" and "cloud" go together.
Netflix.
> 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
> It's hard for me to see how "Java" and "cloud" go together.
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.
Yep:) At a previous job, we also did Jira/Confluence/BitBucket self-hosted, running on what should have been nice hardware, and spent months chasing performance issues, including a charming issue that was so bad that it broke jira for the entire company every... Monday, I think? When you have a well-used standard operating procedure for restarting Jira just to unfreeze it, you have a problem. We were pretty sure it was somebody running a weekly report with some monstrous query, but 1. not even Atlassian support could seem to tell us how to find such an event, and 2. I don't really care how bad the query is - if you can run a query and take down the system for the whole company, then the software is bad. And honestly, even "normal" performance was poor - I seem to recall that it at least acted like the web UI was the slow part; running a local CLI client against the API was faster.
Well they certainly noticed companies running their own Jira hurt the image of Atlassian, and stopped offering the service altogether. It would be a knee-jerk reaction but possible.
Jira is probably the slowest piece of software I use in my job. I can't believe there's an interstitial loading screen with a status bar for cloning an issue.
I've no recent experience of the on-prem version, but nowadays I have to use the cloud version and it's painfully slow. One common problem I encounter is that after a page loads I might want to search for something in the search box. I'll click it and start typing ... then at some point the rest of the page has loaded including the stupid key bindings which do various random actions on different keystrokes. I don't know why they have this, it's infuriating.
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?
Agreed. Hijacking ctrl-f in my browser (chrome) is user-hostile, given searching on-page is a reasonable expectation for any web app.
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.
1. Performance. It is incredibly slow without customization.
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.
At the largest bank I worked with. Trac was the primary wiki that was in use for almost 15 years (largely abandoned for the last 5). Think 10 000 wiki pages and documents written by a thousand developers over the span of entire careers. Note that Trac is abandoned software, for example it cannot run on python 3, there's been issues filled on that for years and there's simply no effort to maintain it.
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.
Open Project https://www.openproject.org/
We use it on the side of JIRA.
It is straightforward to use, can assign group to tickets, gantt charts, cost reporting...
This sounds like a terrible move and will probably force all medium-size organizations I work with to ditch Atlassian.
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.
> 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.
Azure DevOps Server, née Visual Studio Team System, already exists.
If I was going to switch anyway, I wouldn't switch to Azure DevOps Server, I'd switch to GitHub Enterprise. I don't think there's much of a future for Azure DevOps.
> I don't think there's much of a future for Azure DevOps.
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.
I think GP is more referring to the fact that GitHub Actions et al are a better reimplementation of Azure DevOps. I suspect Azure DevOps will be deprecated in favour of GitHub.
> 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
(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.
Azure devops was the first to offer Windows based self-hosted runners - if you’re stuck in the drudgery of building Windows software, because your customers only run Windows servers, it was pretty much the only modern devops option for a while. I don’t think Devops is going anywhere anytime soon, I’ve heard utilization is quite high.
I feel like I've had two experiences with it. Probably 10 years ago I was at a medium sized facility and we migrated 10 different ticketing systems to Jira hosted on-site. It was a little awkward, not quite lightweight, but served all the needs and it was amazing to move tickets between departments while maintaining history and the customization of presentation and fields. Confluence was a much nicer wiki system compared to others at the time and it was nice to integrate Jira/Confluence. Search and Filters are something many other systems suck that for both wiki and ticketing.
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.
Man Asana is a real mystery. It has fewer features and worse UX than JIRA. I constantly have trouble clicking on the right thing or having some auto action just do something unexpected. It's coasting on having a nice stylesheet.
My understanding of Jira is that it by itself does not suck but it bends over backwards for asinine “business processes” so it is difficult to find an implementation in the wild that does not suck.
I know a little about the inside of the jira sausage factory from second hand reports. It's got the "accrete everyone else's business processes" problem that you mentioned, but it's also got the problem that it's quite spaghetti on the inside as well, probably for the usual reason - startup founders writing lots of code in a hurry and conflating the purpose of the software with its architecture due to being too close to the problem. Compound that with the usual startup-in-growth problem of more people than necessary (with presumably very uneven capabilities) working on the codebase and you've got a recipe for a maintenance problem.
I do know that getting put in the jira team is one of the least fun parts of working for atlassian.
I’ve heard this from multiple sources as well. IMHO, atlassian has had lots of opportunity to fix this... they’ve just been too focused on the next shiny object to do the less fun work of refactoring and redesigning the engine layers into something more sustainable.
JIRA is essentially a platform. It is unopinionated and infinitely configurable. This leaves it open to abuse and many orgs will absolutely abuse it. Other products that are popular do very little by comparison. That lets them build a really tight and simple UI but any org with more than vanilla requirements will hit a wall.
Oh, it is very possible. Look at most ITIL software, although it might be hard, they usually don't have screenshots on their websites so the only way to see the product is in the company of a sales person.
I wish we had something even half as good as Jira.
Quite easy, I have am been around for 30+ years in IT and have yet to find something that beats Jira in all its integration options, possibilities of formating tickets information, and flexibility to definie project specific workflows.
Given the option, I will always push for Jira, and associated Atlassian products.
They're both tools to build forms. How horrible the forms are is really up to your organization. Whether they force you to fill 50 mandatory fields or not.
This really does not say any thing outside you have 30 years+ in IT. What did Jira fix? I find what you said fully false given the context of the statements.
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.
It means I have seen a lot in what concerns bug tracking and planning systems, from home grown cgi scripts with a basic form submit to enterprise deployment platforms like DOORS and ClearQuest, with dedicated IT support teams to just keep them running, and anything else that you can think of in between.
> have yet to find something that beats Jira in all its integration options, possibilities of formating tickets information, and flexibility to definie project specific workflows
I think the reason you like it is exactly the reason a lot of people hate it.
possibilities of formating tickets information, and flexibility to definie project specific workflows.
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.
Can you give me some examples of tools that are better? Genuinely curious.
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.
I don't think it's possible to say that one project management project is universally better than anything else. What a team needs out of project management tools varies immensely.
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.
This disagrees with my experience in both systems, especially if you’re using TFS for your build system, too and Visual Studio for programming. TFS was far better.
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.
This quote from Bjarne Stroustroup is very relevant:
> 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.
In our case we're ditching our office and that probably means we'll be using the Atlassian cloud instance (since I imagine our server racks will be scrapped eventually), which might be a trend they're seeing altogether.
> 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.
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.
Microsoft also has Azure Devops, which essentially competes with Jira + Teamcity in one. Confluence is covered by either Azure Devops wikis or SharePoint.
> Microsoft already has GitHub that works fine as a Jira/Confluence substitute for technical people.
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.
This sounds like a terrible move and will probably force all medium-size organizations I work with to ditch Atlassian.
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.
I have no answer to that, but if one is forced to go off of on-prem Jira and go into the cloud, it may not follow that people will go to in-cloud Jira. Once an organization is forced to do work, it may be the opportunity re-evaluate things and find something "better" (local or in-cloud) instead of just renewing annually due to inertial.
Our org uses both Jira Server & Confluence Server - and I’m fairly sure this will make us move away from Atlassian’s products
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[1] 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[2].
Yes, there still is no easy way to migrate Tempo data from Server to Cloud. Their advice is "there's an API - good luck" [1].
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 [2] in looking at such alternatives.
Please stop doing this. Fishing for product insight on such broad opinions in an open forum does a disservice for Gitlab the product and the team. If it was a natural question... But this is so canned, every gitlab employee here does it, sounds flaky and impersonal. Almost troll-like, maybe even arrogant tbh.
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?
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.
Our org uses both Jira Server & Confluence Server - and I’m fairly sure this will make us move away from Atlassian’s products.
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[1] 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[2].
Microsoft is doing the same with Azure DevOps and big orgs with sensitive data are moving there as well. I don't think you can even have Azure DevOps on premise.
So Atlassian is doing it because they know there is no competitor that would jump in. Because everyone else also goes that direction.
> So Atlassian is doing it because they know there is no competitor that would jump in. Because everyone else also goes that direction.
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).
It already exists. JetBrains YouTrack has an on-site version with similar features to Jira, and the latest version comes with a wiki feature called Knowledge Base. [1]
There's also an automatic import process from Jira [2].
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" [3]. The new system rewards employees largely for following the "company values". Under the company values page [4], 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.
Microsoft is busy also pretending OnPrem does not exist, They cancelled all of the OnPrem cert programs, and everything is "Cloud First", with Onprem products being treated as second class with price increases to push people to subscriptions
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.
This is entirely because they had to fork their product and codebase between cloud and on-prem, and their resulting total failure on execution on their internal product roadmap.
Atlasssian has demonstrated a chronic inability over the past few years to maintain feature parity between what are effectively two different products.
Atlasssian has had a really, really terrible feature execution delivery pace over the past few years - "Next-Gen Projects" were so immature at launch they were useless, and have been incredibly slow to mature.
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.
It's insane that they had to that rather than giving their On-Prem version the ability to scale the way you need a SaaS service to scale. Turning your SaaS Ops team into an On-Prem customer is a great way to dog-food your product.
It's not easy unless you begin with that mind-set from day one.
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
I know it's not easy, but it's the only viable path form my experience. I ended up doing something similar, but taking our SaaS product and packaging it in a way that it could be run On-Prem. There was a really interesting feedback cycle where we wanted to make the On-Prem and SaaS deployments work as similarly as possible.
Atlassian's Cloud products were initially (~2009) just the Server products with a few plugins bolted on to unify the UI, deployed in bulk. Over time the backends diverged, and here we are.
Ouch, on-prem software is a really tough business. I can kinda see why companies want out. Especially as they get bigger. Two of my former employers had to go through this hurdle of moving to SaaS from a an on-prem installation.
* 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?
A lot of this seems to boil down to whether or not you're willing to "upset" your users. Yes, sometimes they do dumb shit. That doesn't mean you hang up on them, but "you're out of support and need to update. Call us back when you've updated" is a completely reasonable response, even if the update isn't free. "Your environment is below our minimum specs, you have to increase the hardware on that VM. Call us back when you've updated" is reasonable as well.
I get that telling customers this kind of thing is hard, but sometimes it just has to be done.
"please update" is kinda the "try restarting" equivalent for sysadmins. And people get angry because it is usually delivered in a "I have no idea if it will work" kinda way.
All you would have to do to make people calmly accept that they need to update is explaining why, so you know do the minimum and search the issue tracker so you can tell them that this is actually a known problem that was fixed in version x.y.z and updating will fix the problem.
Yeah, but most software updates have so many bug fixes and performance improvements it's unreasonably expensive to give people a justification for each upgrade request, especially when - as noted - customers accept forced upgrades without any notice at all, when something isn't self hosted.
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.
GitLab pretty much covers BitBucket (code), most of Bamboo (GitLab CI), maybe Jira if you use it only as a basic issue manager (forget about Agile stuff).
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 really wish MedisWiki was in a state that it could be rolled out as a replacement for Confluence. And in a lot of ways it can be. But sadly a lot of companies go the other way.
Most of the places I know of or where friend's work use Atlassian. I am wondering if this will drive a shift towards GitLab considering the general consensus I've heard is that GitHub Enterprise is too expensive.
What agile stuff are you missing from the paid versions of GitLab? We have epics, roadmaps, milestones, and iterations. The only thing that is missing I can think of is workflow enforcement, but that doesn’t strike me as Agile.
Last time I checked I could not modify the fields of an issue (e.g. introduce a random drop-down or a checkbox). Here Jira and TFS were always excellent.
I always go the impression that GitLab was doing excellent in code related workloads but sub-par in issue and test record tracking.
If you likes gitlab and look for better planning capabilities you can have a look at Tuleap [1].
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 [2] due mid november.
It's great for things like blog posts, but not so great for technical documentation. Tables are the key. Also if it had DocuWiki/MediaWiki import tools and PDF/ePub export for print and screen reading it would have been perfect. Markdown doesn't cut it if you have tables, the DocuWiki format seems to be better suited for that but also a lot more annoying for source editing regular stuff and a nuisance for non technical people. We have online docs on DocuWiki. At least we have the option to use Pandoc to convert to printable formats. The thing is that our whole instance looks like a 00s web 1.0 website and it's not searchable. I'm always annoyed when looking for something on it. Your BookStack web app is miles ahead in this regard. I love the chapter collapses.
I wish there were better self-hosted wikis. Most seem to be from the mid-00s and rock the look. None of them have real-time collaborative editing like Confluence or Quip from my research.
We're working on a CRDT collaboration engine at Outline-Wiki https://www.getoutline.com. It can be easily and performantly self-hosted (though there's a saas version available) and it's open-source.
Fair warning that it is under the Business Source License which isn't really open-source. I fully understand why this license was chosen (preventing resellers competing with your SaaS), but advertising as "open-source" is misleading.
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.
Wiki.js seems to be up and coming in this space. It’s not full featured yet, but it feels like working with a modern web application, rather than a bunch of PHP. No real time collaboration though.
The problem is that a lot of people will reach for Gitlab to replace Jira, or MediaWiki/Dokuwiki (or again, Gitlab) to replace Confluence. But for businesses that have adapted business processes to use them, Gitlab/MediaWiki/Dokuwiki simply don't cut the mustard. We have an extensively customized Jira installation that's used for tracking budget requests, cage access tickets, and system change requests--none of those fit into a "bug/task/defect" tracker like Redmine or Github Issues. And for anyone who's gotten a manager using Confluence's editor, moving to writing wiki source in Dokuwiki is a big step backwards.
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.
This. Although personally I have never been a big fan of clunky Atlassian products and as a developer would prefer more productive tools, but getting key non-technical stakeholders use the same system as devs teams is a big win.
- real-time collaboration (e.g. via OnlyOffice or Collabora)
- calendars
- video conferencing
- kanban
- webmail
- 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.
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.
I wonder what will happen with all the plugins that only worked on the "in premise" version of JIRA. I remember at some point going through the offering of plugins and a lot of them where only available for that version.
Jira is amongst the most popular workflow / ticketing systems. Probably number one. Bitbucket is top 3 git hosts. Confluence is one of the best wiki/knowledge base products. They also have some other products I’m less familiar with... but they are pretty big.
I maintain server versions most of the self-hosted applications they're killing off.
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".
I’ve abandoned Jira (cloud) at work so long as my manager continues to not care. It’s just painful. Brutally painful. Like 20MB download per use and everything takes forever to populate and there’s lag in everything I do.
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.
This is a big problem for our non-profit organization. All of our documentation is stored in Confluence. We are fortunate enough to use a free Community license for self hosted servers, but this announcement would remove the free Community license and would force us into a Community Cloud license that would cost us over $4k a year. Are there any good, possibly open source, alternatives available for non-profits?
Depending on what you have, you might look at Xwiki (xwiki.com) or Bookstack (www.bookstackapp.com). I find Xwiki's look-and-feel not as nice as Confluence's, but they have many of the same features and they have a migration guide for importing data from Confluence.
Working with this product in contexts caught between on-premises, self-hosted cloud and fully outsource, with a tussle amongst the consumers/users, the payers and the operators, I predict more argument in my working life as we re-equipoise around this.
We use Bitbucket server because we prefer the code review UI and the diff views over everything else. I was shocked when I tried the cloud version and saw how different and how much worse it was. Would otherwise actually prefer to move to cloud but not with that UI, will re-eval competitors instead.
I don't know about the other products, but I was always told that Bitbucket is literally 2 separate products with unrelated codebases that Atlassian just branded the same. Take with a grain of salt because I have no good source, but consider that ex. on-prem BB never supported Mercurial (which was cloud BB's big selling point for me), and their UIs were quite different.
I don’t know what the products are like today, but you’re right that they’ve historically been two separate products with totally different implementations.
I'm part of the dev team so take this comment with the level of distance you want but you should have a look at Tuleap [1].
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/
304 comments
[ 3.3 ms ] story [ 273 ms ] threadServer 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.
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
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.
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.
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.
I've heard the same about cloud performance, which seems to be an argument against it being simply configuration, but who really knows?
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.
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.
Netflix.
> 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
AirBnb, LinkedIn, Netflix, Twitter, Foursquare, Sony, Shopify etc.
Most of the top tier websites use something on the JVM e.g. Java, Scala.
Given the number of companies known to use Java in the cloud very successfully, this is a “Citation Needed” moment.
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.
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.
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.
Try looking here:
https://alternativeto.net/software/jira/?license=opensource
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.
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.
Azure DevOps Server, née Visual Studio Team System, already exists.
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.
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.
(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.
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 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 do know that getting put in the jira team is one of the least fun parts of working for atlassian.
I wish we had something even half as good as Jira.
Given the option, I will always push for Jira, and associated Atlassian products.
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 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.
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.
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 think this is on purpose to push people to the clould offering.
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.
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
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[1] 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[2].
[1] www.tempo.up [2] https://about.gitlab.com/direction/maturity/#plan
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 [2] in looking at such alternatives.
[1] https://tempo-io.atlassian.net/wiki/spaces/THC/pages/8969584...
[2] https://www.goodbyeserver.org
"Relatively weak issue tracker and wiki" got me interested - mind elaborating in more detail what brings you to this conclusion? :)
Thanks!
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.
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[1] 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[2].
[1] https://www.tempo.io
[2] https://about.gitlab.com/direction/maturity/#plan
That's not really an option for organizations whose main product isn't code, no?
So Atlassian is doing it because they know there is no competitor that would jump in. Because everyone else also goes that direction.
https://azure.microsoft.com/en-us/services/devops/server/
“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).
There's also an automatic import process from Jira [2].
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" [3]. The new system rewards employees largely for following the "company values". Under the company values page [4], they claim one of their values is "Don’t #@!% the customer". Interesting way to show it.
[1] https://www.jetbrains.com/help/youtrack/standalone/Getting-S...
[2] https://www.jetbrains.com/help/youtrack/standalone/importing...
[3] https://www.news.com.au/finance/work/at-work/atlassian-ditch...
[4] https://www.atlassian.com/company/values
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.
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.
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!
* 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 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
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.
Even though most of things the users complained about would have been fixed with upgrades.
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.
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 [2] due mid november.
[1] https://www.tuleap.org [2] https://tuleap.net/plugins/agiledashboard/?group_id=101&plan...
Rather opinionated in design and structure though.
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.
https://github.com/mrvautin/openKB
(It's my start-up.)
[1] https://www.documize.com
https://phacility.com/phabricator/
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?
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.
https://nextcloud.com/blog/nextcloud-hub-20-debuts-dashboard...
- federated file sharing
- real-time collaboration (e.g. via OnlyOffice or Collabora)
- calendars
- video conferencing
- kanban
- webmail
- 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.
https://webo.hosting/
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.
[1] https://www.tuleap.org [2] https://blog.tuleap.org/tuleap-versus-jira-software/
(Disclaimer: I'm from the dev team)
Disclaimer, I am CEO
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.
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.
https://azure.microsoft.com/en-us/global-infrastructure/gove...
That honestly sounds like an oxymoron.
https://www.atlassian.com/blog/announcements/journey-to-clou...
> To focus on the world-class cloud experience you deserve, we are simplifying our self-managed offerings.
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/
[1] https://www.tuleap.org/
It wouldn’t surprise me if they eventually offer some kind of “segregated clouds”-type functionality.