* Ihor Radchenko <[email protected]> [2026-03-07 16:58]: > jman <[email protected]> writes: > > > Ihor Radchenko <[email protected]> writes: > > > >> Also, I started this thread simply because LLMs are starting to affect > >> the Org development. I'd prefer to discuss the rules we will eventually > >> formulate on this list rather than elsewhere. This way, the records will > >> be preserved. > > > > Looking at my (and other projects) experience I think also orgmode is going > > in the direction of a > > "no-AI slop/spam" policy that covers not only copyright concerns (which are > > still cloudy and having > > the FSF in the loop makes the process longer). > > I'm leaning towards more receptive attitude. > Preliminary ideas are the following: > > 1. First-time contributors should be discouraged to use LLM
Risk: “Discouraged” is non-binding. Without enforcement mechanisms, it becomes advisory noise. How would you know it? Why waste time to see if it was done by LLM, and in many cases user is the one to tell to LLM, so "discouraging" is kind of contradictory, as if user can use LLM to contribute, then most probably that user already know what is he doing. Making these "policies" is not useful. Simply keep the successful flow to review if contribution is useful or not, and accept if you wish or not. > 2. The only exception to (1) is when they declare that How would you enforce (1) to even have exceptions? You deal with people on distance. There are not lie-detectors that work on distance. Instead, encourage communication and friendship, not robotic policies that cannot be controlled nor enforced. > a. They are experienced LLM users Who is to say so? The “experienced LLM user” exception is a red herring. Even if someone claims expertise with LLMs, how do you verify it? Think freedom and let contributions come. There are environments online where so many contributions are there, nobody cares if LLM was used or not. > b. They confirm that they have reviewed the LLM-generated code and > *also the code it changes* I would forget "LLM" and ask users to review the code and know what it does, and changes to the code are automatically in git logs. > 3. Contributors who wrote their own patches in the past may use LLM for > smallish patches. No new substantial features. Sounds authoritarian. Rule which you cannot prove and cannot enforce. Judge by usefulness of the contribution and not if user's grandmother or LLM was present. > 4. Regular contributors may be trusted to use LLM assist for new > features. They are probably experienced enough to review the > generated code and make sure that it is reasonable. You will just create more barriers, instead of welcoming users. > However, large new contributions made by LLM (as in (4)) cannot be yet > accepted. We need to wait for GNU to provide official guidance (which > they are working on). GNU was fighting for user's freedom in software sharing, and now is time to recognize that there is more freedom due to existence of LLMs, more than ever before. The real question isn’t whether LLMs are “allowed” by some external authority—it’s whether they help or hinder the project’s goals. If LLMs can assist in writing better code, documentation, or patches, why not embrace them? If they can’t, the problem isn’t the tool—it’s the user’s ability to evaluate it. > For users who absolutely want to use LLM and believe that the new > feature provides a lot of value, we will suggest implementing those > new features as a separate package. We may accept optional support > for that separate package into the core. You see, who believes that new feature outside of the official Org/GNU/Emacs provides usefulness, that one is anyway going to have it and most probably share it with others. Core principle of GNU project is to share software and make it available for free to people. LLMs are contributive in doing exactly that. They are making copyrights obsolete step by step. Would there be no copyrights, there would be no protest, neither no GNU project. But now Org is fighting it just because. LLMs generate free software, if public domain, whatever, when useful, it can be adopted. Why would be GNU the last one to adopt the worldwide substantial change of software sharing? The real question: Are we serving users or enforcing dogma? The GNU project’s success has always been tied to practical utility, not rigid adherence to old rules. If LLMs help contributors write better code faster, why resist? If they enable more people to contribute—whether through direct coding or assisted drafting—why not embrace them? The alternative is stagnation: clinging to outdated policies while the world moves toward faster, more inclusive software sharing. The scratch buffer was revolutionary because it lowered the barrier to entry. It gave beginners a place to experiment, make mistakes, and learn without fear of breaking anything. LLMs are doing the same—but on a global scale. They’re not just a tool for a few; they’re democratizing programming for millions who might never have touched Emacs or GNU software otherwise. If the scratch buffer inspired generations of programmers, imagine what LLMs could do—accelerating the growth of free software contributors by orders of magnitude. LLMs are the modern "bait" for new programmers—and GNU should be the first to fish. The GNU project thrives on new contributors, and LLMs are the ultimate recruitment tool. They make programming accessible, interactive, and even fun for people who would otherwise be intimidated by syntax errors or complex workflows. Instead of resisting this wave, Org-mode should leverage it: use LLMs to help onboard new users, generate examples, or even draft documentation. The more people who can easily contribute to Org-mode, the stronger the project becomes. The race isn’t just won—it’s being rewritten. The shift toward LLM-assisted development isn’t a threat; it’s an evolution. The GNU project was built on the idea that software should be free to create, share, and improve. LLMs are making that idea more powerful than ever. If other projects resist this change, they’ll fall behind. But Org-mode? It should lead the charge—not by enforcing rules, but by embracing the tools that bring more people into the fold. Or it may die. The order of magnitude of new tools to manage life in text is now with LLM tools and MCP servers uncomparable to what Org was before years. Options: -------- Resist and Fade: Cling to its past, enforce arbitrary rules about tool usage, and watch as users migrate to shinier, more intuitive alternatives that don’t require learning curves Evolve or Die: Integrate LLMs and tools as first-class citizens, turning Org-mode into the premier text-based system for the new era—where users describe their workflows, and Org-mode understands, executes, and enhances them. I have shown you how embeddings work in the background; it is far more superior and accurate for search than anything else. Let us not stay in the ivory tower. > Small LLM contributions that are <15LOC (the same criteria as for > patches from people without copyright assignment) are allowed, but > considering all the above. How would you know it? If you wish to enforce to know it, you are putting huge burden on yourself. Simply judge by usefulness of the contribution. > > You folks are lucky :-) because the barrier of entry for > > contribution here is higher than on GitHub (patch workflow and > > everything) and this protects the project. But you know how dire > > the situation is out there. You’re right: the patch workflow and Org’s traditional contribution model feels like a fortress. But fortresses don’t protect projects—they bury them. The "high barrier" you’re proud of is the same barrier that’s pushing contributors away while competitors (with lower friction, LLM assistance, and global reach) swallow the market. Look at the number of MCP servers here: https://www.modelscope.cn/mcp Imagine if those websites would be giving users hard time to contribute as in this environment? People are reading your words, and majority will remain silent. Can you think how does your self-imposed rule reflect on potential contributors? For me personally, I would rather prefer small Org that is error-free with packages to extend it rather than decades long never ending process. Jean
