donbr/markdown-confluence-discovery.md

## markdown-confluence-discovery.md

      
    Raw
  

              markdown-confluence-discovery.md
            
          
    Here’s a concise analysis of the markdown‑confluence GitHub organisation (and its tooling), why it appears to have waned in activity, and alternative tools/approaches you might evaluate.

1. What the project was


The mono-repo at [markdown-confluence/markdown-confluence] described itself as “a collection of tools to convert and publish your Markdown files to Confluence (using Atlassian Document Format – ADF)”. (GitHub)


It included components like:

an npm CLI (@markdown-confluence/lib) for converting Markdown → ADF. (GitHub)
a GitHub Action wrapper (publish to Confluence) via markdown-confluence/publish in the Marketplace. (GitHub)
an Obsidian plugin, Docker CLI, docs repo. So it aimed at Markdown writers (particularly Obsidian users) publishing to Confluence. (Markdown Confluence)


On the organisation page we see the repo “markdown-confluence” last pushed Aug 15 2024 (in the list on the org page). (GitHub)


Other components in the org: publish-action (May 6 2024), obsidian-integration (Sep 24 2023) etc. (GitHub)


So the project was alive until mid-2024 (and some parts even earlier). But there are signs of slowdown.

2. Why it appears to not be actively maintained anymore

Here are observed signals plus inferred reasons:
Signals


After the August 2024 commit, there are no major new pushes visible (at least on the main highlighted repo) beyond that date in the org listing.
The docs site still describes the project in present tense (“we’re excited …”) but no roadmap or active contributor bulk. (Markdown Confluence)
The GitHub Action marketplace page shows version tags (v5 etc) but the number of stars/active maintenance appears modest. (GitHub)

Possible reasons (inferred)


Narrow niche: Markdown-to-Confluence conversion is a useful but relatively niche workflow compared to broader documentation and publishing pipelines. Projects like this often lose momentum once major features are done or adopters are fewer.
Atlassian / Confluence API changes: Confluence’s APIs (Cloud vs Data Center) evolve and keeping up with changes (e.g., ADF changes, permission/space model) can impose maintenance burden. If the core maintainers moved on, costs to continue may outweigh benefit.
Competition / marketplace offerings: If there are stronger alternatives (plugins, apps, paid marketplace solutions) then open-source maintenance may drop.
Resource/time constraints: Open-source maintainers often shift to other priorities; with limited contributors the burden of bug fixes, PRs, changes may hamper viability.

In absence of an explicit “project archived” notice, it may still work but be in maintenance-mode (no new features, only critical fixes) which from a user perspective is “not actively maintained”.

3. Alternative tools / newer approaches

Given your interest in documentation pipelines (and possibly integration with Git, version control, CI/CD), here are alternatives and broader architectural patterns. These may offer similar/better functionality or allow different trade-offs.
Direct alternatives for Markdown → Confluence


mark (markdown to confluence) by kovetskiy: A Go-based tool that syncs markdown docs with Confluence pages (supports attachments, templates) and is fairly mature. (GitHub)
md2conf: Python tool for publishing Markdown to Confluence using REST API; handles directories, attachments. (GitHub)
Marketplace apps: For example “Include from GitHub to Confluence (Markdown, AsciiDoc)” integrates GitHub files, Markdown/AsciiDoc, GitHub Enterprise → Confluence. (Atlassian Marketplace)

Broader documentation alternate architectures


Use static site generators (e.g., MkDocs, Docusaurus) to build docs from Markdown, then publish to docs site (rather than Confluence). This decouples from Confluence’s API and structure.
For compliance or enterprise knowledge graph / documentation workflows (which you might care about given your graph/RAG interests): treat docs as content nodes, publish to a knowledge-graph/semantic store, then surface via Confluence or other front-end. In that case, Markdown→HTML→ADF is only one path; you might directly render from doc/graph to UI.
Use GitHub Actions/CI pipelines to convert Markdown to multiple targets (CONFLUENCE + web site + PDF). A tool like the markdown-confluence suite could still fit, but you could build “glue” around more generic converters (Pandoc etc). For example, use Pandoc as base for conversion to Confluence storage format or intermediary HTML/ADF. (Wikipedia)

Recommendation given your architecture lens

Given your interest in scalable, real‐world architectures (graph/RAG, retrieval, observability):

If your docs are part of a larger knowledge graph (e.g., code context + semantic metadata + versioning), you may not want to rely purely on Confluence UI. Consider separating content storage (Git + Markdown + versioning) from publishing layer (Confluence or web front-end) and treat Confluence as one of several output channels.
Evaluate the cost of maintaining the Markdown→Confluence pipeline: if you need heavy customization (metadata injection, linking to graph nodes, retrieval metadata) then a generic converter may not suffice. A more custom pipeline (Git + conversion + attach to Neo4j/knowledge-graph + display via custom UI) may be better.
If you still go the Confluence route, choose a tool that is well maintained (e.g., mark, md2conf) and ensure you have in-house capacity to adapt it (e.g., fork and extend) rather than relying on a tool whose maintainers may no longer invest effort (like markdown-confluence appears to have scaled back).


If you like, I can check the commit history in deeper detail (issues, PRs, contributor activity) for markdown-confluence to identify when the slowdown happened and what issues people report. Would you like me to do that?
No results found