[HHad3]

Using Atlassian cloud products is a business risk. They previously let customers sit for weeks without access to their data [1]. Cloud-hosted products do get early patches for unsecured /setup routes though [2], so there's that.

At this point the decision has been made in our org to firewall their products off the internet and internal networks, and migrate to something else by 2024.

[1] https://hn.algolia.com/?q=atlassian

[2] https://confluence.atlassian.com/security/cve-2023-22515-pri...

[neovive]

We're in the same boat. I brought Confluence into our org almost a decade ago — it was the best collaborative wiki tool at the time. Over time the price has increased while the quality of the tool has not kept pace with other options. This seems to be the trend as software companies grow into large "enterprise" providers.

Looking at our Confluence usage over the years, I noticed that we use it primarily as a knowledgebase/documentation tool and less for collaboration. With our on-prem license expiring, we are migrating to a dedicated knowledgebase for our FAQ and frequently changing content and switching to a Markdown tool + Git for our more formal documentation.

[unethical_ban]

>I brought Confluence into our org almost a decade ago — it was the best collaborative wiki tool at the time

I respectfully disagree with that assertion! I remember 2012 (okay, 11 years ago). I had just joined a new team at work, and the documentation for the team was a lot of vendor PDFs and some .txt files from the lead stored on a network drive.

The company was just implementing Confluence, but it was slow on client and server side with no HA. That is the fault of the server team, not Atlassian, but still the software was ick.

I spun up a shadow-IT Dokuwiki server that was much easier to use for a small team with text-based documentation needs. It had a naive "calendar" plugin that allowed the quick creation of pages based on date, which we used for oncall hand-off. Backup was zipping the data folder on the server.

It was probably 3 more years until our hand was forced to use the "enterprise standard" for business continuity purposes.

[gwright]

Could you share what markdown/git tooling you've identified?

[neovive]

Sure. We're focusing first on converting everything to plain Markdown and using a Git repo to manage the content. Writers can use whatever Markdown tool they prefer for this. (I'm using Obsidian and others are iA Writer.) I have yet to decide on the docs publishing tool, but I'm testing Astro, Vitepress, and Markdoc for publishing. I'm leaning towards Astro since it's very flexible, easy to add small bits of interactivity via MDX, and has a nice collection of themes. VitePress is also very nice, super fast, and very easy to publish. Since only the developers and tech writers need to collaborate on the docs, we're following a docs-as-code approach — using GitHub issues, comments, and pull requests.

[teachrdan]

Here's some info about Astro for folks like me who didn't know about it before:

"Markdown is commonly used to author text-heavy content like blog posts and documentation. Astro includes built-in support for standard Markdown files that can also include frontmatter YAML to define custom metadata such as a title, description, and tags."

https://docs.astro.build/en/guides/markdown-content/

[paradox460]

You should take a look at foam. It's a toolchain for notes and such, similar to obsidian, but open source. It's main interface is a vscode plugin, but has HTML generators and such, as well as just being markdown, so you can use Pandoc or anything else to make HTML out of it

[snapplebobapple]

I wish people would link software they recommend, because it saves me a lot of confusion when they are semi obscure. I believe this is the software you are referring to? (I'm using obsidian but don't like that it's not opensource and don't like logseq, except for their journals feature so I'm actually quite interested in checking out foam) https://foambubble.github.io/foam/

[paradox460]

Yeah that's it. Sorry for not linking it, I originally wrote that comment on mobile

[HankB99]

Not speaking for the GP. I use MkDocs and keep my personal notes. The only weak spot for me is that I haven't fully grokked search and as my notes grow, it can be harder to find things. I alternate between figuring out how search and how to bolt on some other search utility.

MkDocs includes a utility to publish to Github pages but I keep my notes on a self hosted Gitea server and serve using "python -m http".

[squidfunk]

Author of Material for MkDocs here. We're currently working on re-architecting the entire search engine and rewriting it from scratch. We're currently based on lunr.js, which is unmaintained as of 2020 and has more or less run its course. We've learned a lot what matters in respect to efficient and user friendly documentation search, and can't wait to give the first version into the hands of our users. I'm convinced that the next iteration of search we'll be releasing will solve many of the shortcomings that our current implementation has. Of course, it will work on the client side as it does now, no server needed, but there will be other options as well, e.g. for when your search index is in the megabytes and too big to ship to clients.

[HankB99]

Many thanks for your efforts here. I'll be looking into Material for MkDocs (the next time I can't find something. ;) )

[nvm0n2]

Take a look at mkdocs-material, it's not just a theme, it adds some local-side search as well. Still with fully static pages.

[dnsmichi]

The search works great. I'm using MkDocs with Material as my personal handbook because of the simplicity -- for example, I usually remember great articles in conversations but always forget their location. Since I started writing my newsletter https://opsindev.news/ including an MkDocs web archive, I can share interesting URLs way faster :) Or let folks discover it by themselves, using the search.

Configuration in https://gitlab.com/dnsmichi/opsindev.news/-/blob/main/mkdocs...

Material for MkDocs also has an insiders build, accessible through sponsorship. https://squidfunk.github.io/mkdocs-material/insiders/ These features add more value to MkDocs -- I initially joined to get GDPR-compliant cookie banners and stayed to support a great project.

[wredue]

Is this a fully collaborative tooling with self linking?

Having hundreds of out of date, and insecure word documents is a dismal affair when you get a call in the middle of the night.

For issue resolution, documents steps are moving right in to the ticketing system for linkage to incidents. That’s fine.

For general documentation though. It doesn’t belong in the ticketing system and what a pain in my ass.

[HankB99]

If I understand your question, it's a lot simpler than that. (Simpler as in not that functional.) It represents the directory structure as cascading menus.

I edit using VS Code and it provides help with linking from one document to another, including navigating to the file and even linking second level ('##') headings. MkDocs can report broken links when it builds the site.

Collaboration could be through sharing a Git repo. Perhaps other other ways I can't think of at this moment. Any way you could collaborate editing text files should work.

[gwright]

Has anyone identified an easy/feasible way to add SSO authentication to github pages?

[kosikond]

OTOH couldn't it be done with Cloudflare Zero Trust ?

Have the GH Pages (sub)domain proxied with CF, protect the URL with Zero Trust, for SSO itself there are several IdP available [0]. First 50 users are not billed.

[0]https://developers.cloudflare.com/cloudflare-one/identity/id...

[TheNewsIsHere]

I haven’t tried doing this, although I’ve thought of it to solve a similar problem, which I ultimately solved by not bothering and just letting GitHub render the docs. (Purely internal technical use cases, so not an issue.)

I haven’t experimented, but my first attack would be to query the GH Pages service directly and specify the host header. Bypass Cloudflare entirely.

GitHub Pages supports SSO with the enterprise cloud plan, of course.

[spondylosaurus]

https://www.twilio.com/blog/keep-internal-docs-secure-okta-n...

This is one, although you'll need to use Netlify instead of GitHub Pages proper.

[kriberg]

We use azure ad for authn to our github organization. That also covers github pages generated from those repos.

[gwright]

I assume that means that every person accessing the pages also needs a github account? I don't mind a requirement for a github account for anyone contributing to the repo but I would like authenticated access for viewing the pages that doesn't require a Github account.

[vorpalhex]

For something quick and easy consider https://github.com/gollum/gollum#markups which powers Github Wikis.

Note that multi-user auth is NOT supported out of the box however.

[belthesar]

Obsidian is a pretty good solution for this in my experience

[vorpalhex]

Obsidian does not support collaboration.

It's a fantastic tool but strictly singleplayer.

[kepano]

Obsidian has a feature called "Shared vaults" which teams use to collaborate. You can also use a shared Git repo, or other cloud/network storage (e.g. Dropbox)

https://help.obsidian.md/Obsidian+Sync/Share+remote+vaults

[belthesar]

I used it with a team of 10 folks at my previous job. Everyone worked in a common git repo, and with some smart usage of .gitignore, we were all able to collaborate quite effortlessly, even going so far as to push videos, images, etc to the repo with git-lfs to make the documentation rich and available. It can certainly be multiplayer with a modicum of effort.

[Zetobal]

Wouldn't be feasible for most of our users but nice to know...

[dangus]

As a former Atlassian administrator, I believe the opposite. Maintaining the system on-premise was a bigger risk.

The products are too complicated to be packaged nearly with a bow for sysadmins. You inevitably start having to become at Atlassian SME just to keep that shit running.

I’m all for your company going with an alternative product, but for a company who would rather stick with Atlassian products, you’d be insane to prefer the on-premise version.

Either insane or you’re a giant company with heavy compliance requirements and you don’t mind hiring a dedicated person/team to operate the data center product and babysit other on-premise vendors’ services.

In my experience, I was running an on-premise Jira installation for a <100-person company, which was an insane waste of my time compared to the other tasks I could have been doing to help build our core product.

[dzikimarian]

Completely opposite here. We ran jira for many years on-prem, it was mostly effortless - maybe a few man/days per year? (user accounts in low 3 digits, but we kept workflows simple and ran light on plugins).

I'm curious what were actually tasks that wasted your time?

[Aeolun]

How is the product so terrible that running a 100 person instance is a pain in the ass?

[smileybarry]

Classic JIRA is very flexible into shaping a workflow, but it's sort of a very long pipeline of: schemas, fields, workflows, project templates, etc. I loved that flexibility and being able to drill down into a bug report, but it definitely took time to set up, and occasionally unravel & put back together when you needed to fix something small.

There's also the usual stuff of finding & setting up plugins, and then looking for a maintenance window that people can agree on, while side-stepping those settings you forgot needed a restart to apply (thus bringing your live maintenance to a halt because you can't bring it offline now).

[belthesar]

Running core versions of the products aren't terrible - usually the complexity comes with the slough of plugins that folks install to customize the platform, all needing to stay up-to-date.

[kwanbix]

While Jira does many many things right, it is also horrible in so many ways.

What options are you evaluating?

[preisschild]

Not OP, but we moved to Gitlab Issues.

Project Managers are missing some features, but the devs (including me) like it a lot more due to integrating so well with PRs/commits.

[shagie]

One of the challenges of Gitlab is that the pricing does not work well in organizations where a significant portion of accounts would need to be non-developer roles.

With devs and a premium tier, this isn't bad... but the "ok, we need to double the user count and move from premium to ultimate, even though most people are only looking for multi-level epics and the reporter role." That represents a significant cost increase.

Taking all the devs from $29 to $99 and doubling the accounts is a lot more than $15 per account (devs, ba/pm/mgr, business).

[bunderbunder]

This is a problem for so many SaaS development tools.

[Aeolun]

Github is fairly cheap, even at enterprise level.

[bastardoperator]

MSFT also does volume discounts and if you have enough spend they'll give you GitHub for free when renewing VS licenses. I'll take GH anyday over Atlassian when it comes to collaboration.

[wdfx]

The problem with this though, is that commonly a requirement (ticket) does not map exactly to a single code repository.

I feel that it is breaking encapsulation in a sense to be dealing with issues at the repo level. The repo and the code are implementation details of the business requirements. The tickets describing requirements belong at the next level up of abstraction?

[mushakov]

Hi there! I lead the product teams for planning features at GitLab. Issues at the group level are in the works to meet this exact need. You can follow the work in this issue https://gitlab.com/groups/gitlab-org/-/epics/8308 . As always, would love to hear from you in the issue if you have feedback about the approach or have follow up questions.

[wdfx]

Thanks for providing this info.

I do use gitlab-ce at home for my personal projects and think it's awesome.

I would recommend it to work in terms of its features for code management and build pipelines.

But I just cannot see any of our product management team wanting to use this for Roadmap/Epic/Task tracking at all. Its far too technical and too close to the code, both of which are things they have neither the time, interest or skill to interact with. Management are comfortable with Jira (and some of the extended Atlassian suite), as it hides the technical stuff away and allows them to focus on the management data.

I don't know what the perfect solution looks like though, and I also haven't spend the time to exhaustively try all the competing products either.

[arueda]

Hey `wdfx` GitLab team member here. :)

>[Roadmap/Epic/Task tracking] Its far too technical and too close to the code

I'm a Product Manager in the Plan stage at GitLab and I'd love to learn more about this impression. Would you be willing to share more either in thread or on a call?

Specially, I'm trying to understand what about the GitLab Plan tools (epics, roadmaps, etc) feel dev-centric?

[peanball]

There are issues at group / org level in GitLab that can span such tasks.

[imp0cat]

Also, you can create a special project to keep general issues (and use CI in this project to run Gitlab Triage bot to help you with issue management).

[john_cogs]

GitLab team member here.

One way to approach this would be using Epics [0], which can live at the group-level. Child epics and/or issues can then be used for more finely tuned requirements.

0 - https://docs.gitlab.com/ee/user/group/epics/index.html

[afandian]

I should point out that multi-level epics are only available at Gitlab's $99 per user per month level. We wanted to use them, but it's not worth that much. Jira is a lot more flexible and cost effective in this regard.

[kwanbix]

99 per user per month is crazy expensive IMHO.

[brightball]

Project Managers might just need some training. The board system in GL is very flexible and adaptable to how your org works.

I was really impressed.

[mushakov]

YAY! I work on planning features at GitLab and Gabe from my team put together this overview view if any of you want something you can share with your team for training https://www.youtube.com/watch?v=KmASFwSap7c . You can also find agile planning tutorials in our docs site https://docs.gitlab.com/ee/tutorials/plan_and_track.html

[jillesvangurp]

There is no perfect issue tracking system sadly and integration with prs and commits actually is becoming a hard requirement for me. This is not something that people should be updating to an issue tracker manually, ever. Or doing without entirely (more common). Also nice in Github is the integration with Github actions and being able to see whether something can be merged safely or not.

I double as a product manager and CTO, meaning I do both code and planning. We're using Github issues and Asana. Both have their strengths and weaknesses. I'd take both over Jira any day. And since I'm in charge, my company is blissfully free of anything Atlassian.

I kind of like Asana for planning. It's got a few sane features one of which is separating issues from projects. This allows me to quickly plan out projects and then add tickets to the relevant team boards. And another one is making it very easy to create issues in a spreadsheet like view that minimizes the click bureaucracy other tools have. Great when you basically are thinking at the bullet point level and just want to hit enter instead of having to fiddle with obnoxious modal forms.

Of course for developers Asana isn't great because it has no markdown support and no usable github integration (a few commercial things exist but they are basically glorified sync tools). Github issues have a few nice features as well. I like working with check lists and then converting the individual items to tasks. That comes close to how I like to use Asana.

Where Github falls off a cliff is what passes for project management. I don't know what their PMs were smoking but it's just completely wrong and useless. It kind of lives orthogonal to issues (!!!!!) and nothing syncs automatically except with really awkward github actions crap. So, it only serves to add a lot of bureaucracy and busy work without actually addressing the core problem. A combination of over engineered and inadequate.

The core issue with Github is that issues are tied to a single code repository. From a planning point of view that is just horrible because I manage a product consisting of multiple code repositories and I need one plan that may involve zero or more code repositories and not several and I don't want to lock in my issues to a single repository before I have even figured out what the plan is. I guess that's what they tried to fix with their project management thingy. Except they messed that up badly.

I'd love a tool that is a bit like Asana but more integrated with pull requests, CI/CD, the notion of work being distributed across multiple code repositories, teams, etc. I don't mean yet another sync thingy that copies tickets from system X to system Y. I would like a one stop shop that can be used throughout the life cycle of a software product from before any code is written until users / customers start reporting issues and everything in between. Doesn't exist.

[HHad3]

We've moved to plain markdown in Git(Lab) as Confluence replacement. A CI pipeline compiles it to HTML and hosts it on the web via Material for MkDocs.

It lacks most collaboration options for non-developer users, but we found that they are rarely, if at all, used anyway. Non-developer users can still use an edit button that points to GitLab's web editor and update the docs that way.

I can't suggest a replacement for Jira at this point. I don't think there is one tool to recommend that fits every company's workflow. The other comments seem to have some nice tools to try.

[dnsmichi]

GitLab team member here, thanks for sharing.

> It lacks most collaboration options for non-developer users, but we found that they are rarely, if at all, used anyway. Non-developer users can still use an edit button that points to GitLab's web editor and update the docs that way.

Maybe the wiki in GitLab provides a possible path forward. https://docs.gitlab.com/ee/user/project/wiki/

The wiki uses the same Rich Text editor as known from issue/MR comments, aiding visual editing with context actions - for example, Markdown tables, rows, columns, or uploading and resizing images.

> Material for MkDocs.

I personally love this project. I'm using it for o11y.love and opsindev.news published via GitLab pages. Editing happens mainly in the browser, using the Web IDE.

Sources in case you are interested:

https://gitlab.com/everyonecancontribute/observability/o11y....

https://gitlab.com/dnsmichi/opsindev.news

PS: Tip for faster editing files using the Web IDE in the browser: Press `.` on a repository view which opens the Web IDE immediately.

[galangalalgol]

Gitlab and github are a lot more than simple markdown. They support a lot of additions like equations, and mermaid graphs. The only thing I've used confluence for that won't work in out of the box gitlab is a circuit diagram. And the right way to do that was probably to have the pipeline generate an svg from the circuit simulation model, not draw it.

[DaiPlusPlus]

Despite the "Azure" name, Azure DevOps Server (formerly Team Foundation Server), is still a rock-solid on-prem system for git repo hosting, issues/stories/projects, build automation, and the rest - though I feel it has stagnated somewhat, and git integration still feels half-baked compared to TFS's previous SVN-clone, but is still my first-choice for on-prem installs (granted, I'm still wedded to the MSFT stack).

[whoopsie]

ADO is the death knell to collaborative modern teams. Who the f wants to waste their day with that UX and feature set?

[DaiPlusPlus]

> Who the f wants to waste their day with that UX and feature set?

TFS' UX is hardly any worse than Jira's.

BTW, if your complaint is based on your personal experience dealing with hideously complex Issue/Bug form-fields, "areas", and the like, then that's not so-much an issue with TFS/AzureDevOps, but with your PMs, who are the ones responsible for applying customizations to the built-in workflow forms. The stock workflow forms/fields are a (relative) breeze to use compared to Jira, IMO (but GitHub Issues+Projects are better, I agree).

[datadrivenangel]

ADO makes me yearn for Jira because of how slow and clunky it is.

[twisteriffic]

Having been forced to daily drive both for the past few years, I'd take DevOps over Jira any day. Neither is great, but DevOps has had 100% fewer incidents of adding a comment to the wrong issue because of a dog slow UI that's chock full of race conditions.

[WorldMaker]

If you have access to Azure DevOps Server your company likely also has access in its existing plans to GitHub Enterprise (on-prem) as well. GitHub Enterprise is usually about 6 to 9 months behind GitHub "Regular", but that's quite a bit better than Azure DevOps "Regular" which now seems destined to be 2-3 years behind GitHub and however far Azure DevOps Server trails behind that.

Microsoft is still playing "will they/won't they" with killing Azure DevOps for whatever reasons make sense mostly only to themselves, but it is hard not to wonder if the writing is on the wall to migrate to something like GitHub Enterprise sooner rather than later.

(Arguably yes, running GHE is different than Azure DevOps Server, as it is still mostly not Microsoft-stack. But I'm told they package it in a friendly enough way that even companies deep in Microsoft-stack-only don't have too many problems.)

[TheNewsIsHere]

I keep hearing rumors that I can’t corroborate that the decision has already been made to kill Azure DevOps but that there won’t be an announcement until there’s a timeline. I’ve never seen it in black and white. I’ve seen that comment several times on HN, but it’s always so couched that it’s sort of useless.

It seems like one of those rumors that doesn’t die, and then just becomes self-fulfilling if they ever do announce it.

[WorldMaker]

Microsoft's "on the record" voice is always "Azure DevOps is alive and has an active roadmap".

You can read that roadmap for yourself. It is kept in a GitHub repository. Last time I checked this year the last commit was sometime in 2020. The last group of features that loudly launched for Azure DevOps were branded "GitHub Advanced Security for Azure DevOps". (This is where I get the 2-3 years behind GitHub metric.) Microsoft's actions seem to be speaking a lot louder than their "on the record" words.

I've heard from multiple "off the record" sources who are entirely hearsay and I cannot name names that "Yes, of course Azure DevOps is dead."

The best, I can say, as mostly an outsider is that Azure DevOps is at least "undead" and definitely in some sort of zombie state. I've got an unsubstantiated feeling, again as mostly an outsider, that Microsoft is somehow superstitious about Azure DevOps' home office (Microsoft office in North Carolina was founded out of Microsoft's source control dreams) and is afraid to kill it.

[DaiPlusPlus]

I used to work at Microsoft, though I left a few years before MS purchased GitHub. Post-2010s, Microsoft was still migrating many products away from Perforce/SourceDepot and into TFS, and then TFS+git around ~2015. Microsoft hacked TFS to be a git server so they could continue to use TFS for work-item/project-tracking (and no-one wanted to go back to Product Studio). That’s TFS’ strength, as far as Microsoft is concerned, because git hosting is a trivially fungible feature here - whereas GitHub’s Issues only works well for small teams and really doesn’t scale to projects on the scale of Windows or Office.

…but I’ve noticed that GitHub’s recently (since 2020?) has really being fleshing-out their Projects/Issues - it’s not quite as flexible as TFS/AzDO’s Work-Items but on-track to reach parity in a few more years, I reckon.

So that’s my pet-theory: eventually GitHub (and GitHub Enterprise) will reach “good-enough” parity with AzDO for Issues/Work-Items/Project management - and as soon as that happens I fully expect AzDO to die an unceremonious death (because MS doesn’t want to spook the many Enterprise(TM) customers who still bankroll it). We may-or-may-not see some improvement in AzDO-to-GitHub migration tooling, as that that comes down to what side of the bed the Director of the ALM team woke up on that morning.

[brobdingnagians]

YouTrack by Jetbrains is very good

[dzikimarian]

It's nice, has most of Jira features that were important for my org. Philosophy is bit different in some parts (eg. backlog management), so there was some complaining, but overall it's ok.

Only one major complaint: For main license, you can buy and own license for selfhosted version. However for helpdesk addon it's subscription only, which sucks a lot. For Spaces they have only subscription-based pricing, even when self-hosted. I hope they don't go Atlassian way.

[Jwarder]

Can anyone speak about YouTrack/Space's warts? The marketing blurbs makes Space + YouTrack look like a decent replacement for Jira + Confluence + Bitbucket, but I don't recall ever hearing a developer talk about it.

[nvm0n2]

YouTrack is pretty great. So is TeamCity and they integrate well. The JetBrains instance is open so you can just sign up for an account there and play with it. Also you can run them both on-prem and they're pretty easy to admin if you do.

Space I haven't used. It seems like an attempt to reinvent both products in a GitLab style product which is a pity because the JetBrains tools are very mature and I don't think they needed a new product.

[smileybarry]

A decade ago when we used JIRA team-wide and not org-wide, some teams internally preferred YouTrack so they used that (until the whole org moved to JIRA). What bothered me personally was that fields were basically "unschema'd" and everything suggested every value -- everything was effectively a label field -- including typos, which are more common in a company where English is second language.

But that was a decade ago, and it could've been a misconfiguration on that team's part. It was also back when JIRA was more of a structured database with real issue types and not stories atop stories for all eternity.

[rpy]

Linear is awesome

[apple4ever]

Linear is very much awesome. Still some work to make it really great, but it's awesome right now.

[tedivm]

Slab is an excellent replacement for Confluence, although it doesn't help with Jira.

[zeroonetwothree]

Jira has like 100 alternatives. The best one depends on your exact needs.

But Linear is goated

[ozim]

I would say using on-prem products and never updating them because of penny pinching is much bigger business risk.

[yjftsjthsd-h]

What business risk does that incurr?

[belthesar]

Other than running a highly complex web application that would no longer be receiving maintenance and security patches, of which due to its age and stack appears to be a frequent cause for concern, I'm sure not much.