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

[Tim Cross <theophilusx@gmail.com>]

Ihor Radchenko <yantar92@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> I think your working off a false premise. Your view is that org mode
>> should be available in other editors/software so that others can realise
>> the power and benefits it provides. I can understand that position.
>
> A clarification: my premise is that org mode should be available in
> other _free_ editors/software. If we provide the means for other free
> software to support Org mode (either as markup format or as some subset
> of Elist implementation), it will benefit software freedom in general.
> Whatever helper information (think of tests) we provide, it should be
> licensed under GPLv3 with the following effect:
>

I don't disagree with this objective. My objection is to changing the
emphasis or priority of org mode as an Emacs mode to a general technical
specification for a small part of what is org-mode, the markup (I will
outline the concerns I have in doing this below). The other point of
course is that if you make it easier to implement org markdown in other
editors, you don't have control over whether they are implemented in
free or non-free solutions. 

> https://www.gnu.org/licenses/quick-guide-gplv3.html
>>> It's always possible to use GPLed code to write software that
>>> implements DRM. However, if someone does that with code protected by
>>> GPLv3, section 3 says that the system will not count as an effective
>>> technological "protection" measure. This means that if you break the
>>> DRM, you'll be free to distribute your own software that does that,
>>> and you won't be threatened by the DMCA or similar laws.
>
> The fact is that e.g. Github already provides support for Org markup.
> They do it for their own profit and we cannot stop them. If we have a
> controlled criteria about quality of third-party Org mode support, there
> will be means to interfere with non-free software attempting to makes
> profits out of Org mode. For example, if Github do not integrate our
> recommended test suite (with all the legal consequences defined in
> GPLv3), we will be able to have a list of third-party tools and, among
> free alternatives, mention that Github support for Org is not verified
> and most likely not consistent with other _free_ tools. We cannot do it
> now.
>

There is a fatal flaw in this argument. The GPL licenses code, not the
underlying idea (which is essentially what patents are about). We can
define all the quality criteria we like for 3rd party implementations,
but we cannot enforce them unless they are also using the GPL'd code. As
this code is elisp, it is extremely unlikely any 3rd party
implementation will be using it. In short, defining clear specifications
and minimal quality criteria will only have baring on code added to org
mode - it would, for example, have no effect on what github has/is
implementing. 

>> However, the FSF position would be exactly the opposite. They would
>> argue that orgmode is a powerful and flexible tool that is part of Emacs
>> and if you want that power and flexibility, you need to use Emacs. Org
>> mode has probably done more to bring new users to Emacs than any other
>> Emacs mode in the last 30 years. As a consequence, you will find not
>> only little support towards making it available in other editors, you
>> are likely to run into active resistance. As you say, org-mode can be
>> thought of as a brand name and that is a brand name owned by the FSF as
>> an official GNU project and a goal of the FSF is to convert people to
>> use GNU free software. Anything which has the potential to take the
>> power of org mode and make it available in non-free software (not simply
>> open source) is not going to be supported or welcomed.
>
> I am very much sceptical that third-party tools can provide the level of
> Org support Emacs does provide. Emacs is and will remain the most
> feature-full tool for people to use Org mode. Org mode's largest power
> is configurability thanks to Emacs. On the other hand, Org mode's
> support would be welcome in tools like TeXMacs or in forges like
> Sourcehut (currently only supporting markdown).
>

I don't disagree about the benefit of org markup being supported in 3rd
party tools. I disagree with the proposal to change the emphasis of the
org-mode project from being an Emacs mode to being a more general
technology.

Consider this contrived scenario.

We have adopted a change in emphasis to promote org mode as a more
general solution and clarified the specification to make it easier for
3rd parties to implement.

Meanwhile, Emacs development continues and new features/capabilities
continue to be added. In particular, a new feature is added which is
extremely powerful and would be a huge benefit for Emacs org-mode users.
However, there is a problem. In order to take advantage of this new
feature, significant changes are required for the specification. This
will result in implementations requiring considerable work in order to
update them to the new specification. Worse still, the nature of this
change means that only Emacs org-mode users will benefit from this
change. The change will not realise any benefit for 3rd party
implementations.

Now we have a problem. Either Emacs org mode users must give up on this
great new feature or we break compatibility with 3rd party libraries.
However, if the user base of the 3rd party implementations is much
larger than the Emacs org mode user base, there will be strong pressure
to not make this change.

An extreme scenario to emphasise the point that moving org-mode from
being primarily and Emacs mode to being a more general technical
solution could easily have adverse impact on the development of org mode
for Emacs users.

I also have a more fundamental problem with the whole premise regarding
org markdown and 'bringing it to the world'. This will likely be
controversial, but ....

There is nothing fundamentally better or more powerful about the
markdown dialect used by org mode over any other markdown dialect. In
fact, other markdown dialects are possibly even better than the one used
by org mode.

The power of org-mode is in all the non-markdown functionality - section
folding, table formulas, executable source code blocks, powerful link
definition facilities, noweb/literate programming support,
planning/tasks/scheduling/time tracking, multiple back end target
exports etc.

To some extent, all these issues about markdown and compatibility in 3rd
party libraries and editors is actually a consequence of org mode being
defined at a point where markdown was relatively new and still somewhat
immature. I see parallels here with much of the Emacs terminology which
new users find very alien. The Emacs use of frames, windows and buffers
or even the default key bindings for cut, copy and paste seem weird
these days. However, they were novel new concepts when Emacs implemented
them.

It is similar with org markdown. At the time it was implemented, it was
compatible with one of the best known and popular markdown dialects and
one of the few to have actually written down it's specification.
However, things evolved and now we have a handful of popular markdown
dialects and the one org adopted is no longer as popular. If org had
been developed later, it could well have adopted a different markdown
syntax, possibly github flavoured for example. If this had occurred, we
would have been more compatible with many 3rd party libraries and much
of this debate would not exist.

We have had many threads discussing how to increase compatibility of org
mode in 3rd party applications and many good suggestions. Unfortunately,
they usually amount to nothing because while ideas are cheap, action is
not and often we get caught up on side issues which are not actually
that important (at this stage at least). Forget about changing the
emphasis or search engine results etc at this time. Focus on the more
concrete components, like a clear specification of syntax, good unit
tests and definitive reference documents. Just these three items
represent a huge amount of work and all are likely prerequisites for
establishing a vibrant 3rd party ecosystem. Worry about the rest later.