Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Russell Adams <RLAdams@AdamsInfoServ.Com>]

On Mon, Dec 06, 2021 at 09:59:42AM -0800, Tom Gillespie wrote:
> I think it is a major strategic mistake to exclude discussions
> about interoperability from this list.

I don't think discussion on the list (or irc) is a problem. It's all
on topic if it's related to Org-mode. As you said, users and
developers share the mailing list. Just understand as an Emacs mode,
it's Emacs oriented and Emacs is the priority. The truth is Org
doesn't work outside Emacs.

The issue is when non-Emacs enhancements or feature requests are made
to the maintainers and coders. I don't think anyone is hostile to
interoperability, but hostile to additional workload.

I've watched Org since shortly after it's creation snowball features
nonstop until it burned out coders. I feel like every power user with
a new edge case feature wants it added to the Org core, and that's
just not sustainable. That's why I'm very cautious about advocating
for new features, or potential burdens external interoperability may
place on our volunteers.

> I follow this list, I keep the community up to date with my work,
> I have no idea where to look for other Org related dicussions,

IRC. #org-mode on Libera.

> Whether a certain portion of the Org community likes it or not,
> there is another portion for whom Org syntax already has a life
> beyond Org mode (e.g. academic papers and computation notebook
> style workflows).

Ideally written with Emacs, and the source blocks processed by
Emacs. I can't imagine any of the data science source blocks working
in any environment outside Emacs today.

If other programs try to replicate Org's features that's fine in the
spirit of open source, but what support do we owe their
implementations? At what point does their project impose a maintenance
burden on our volunteers? That's what we need to be careful of.

Perhaps it's worth noting the clear distinction between Org's plain
text format and the Org experience inside Emacs. I think that the
plain text format in it's simplest forms may be interpreted by
external tools (ie: README.org on Github is HTML formatted). I don't
expect any tools outside of Emacs to provide the Org editing
experience.

> The plain text nature of Org syntax and the freedom that it enables
> also means freedom from Emacs. Empowering users to own and control
> their own data to use with their own tools is the whole point. The
> fact that this means that it works outside Emacs is a critical
> feature for many data preservation use cases.

Certainly Org is future proof because it's plain text. There's a big
difference between future proofed and openly legible versus
programming two way interoperability between Emacs and an external
tool. Just ask any synchronization tool. ;]

In summary, don't assume hostility to interoperability. Please respect
the limited time of our coders and maintainers, and the additional
burdens on them that may be implied by supporting external programs.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3