Org is a general-purpose information management hypertext system for Emacs
One of the most common philosophical misunderstandings that I see people have about org-mode is that they assume that it must have a particular intended workflow, like any other literate programming, personal information management, project planning, note-taking, or other similar such system.
This makes sense, since org-mode does represent a cohesive thing, the closest analogue of which, for most people, is some kind of application: after all, it's not just a notation, but a set of interfaces, functionality, and presentations deeply integrated with that notation – possibly integrated to the point of the two almost being completely identical, since anything that isn't literally org-mode.el really isn't "org mode," even if it uses the same syntax.
Despite making sense, however, this misunderstanding causes problems for people trying to figure out how to use the system. It's often unclear to them how to even begin, because they're looking for a specific place to start or way to approach using the system, or expecting to find a tutorial that explains the expected workflow from beginning to end. Instead, all they find is a 600 page manual documenting a dizzying parts manifest of features the vast majority of which they won't even be able to absorb, let alone intuitively understand how these strewn-about component parts in the abstract might possibly be assembled into a concrete, working workflow. This often leads to questions about the "right" way to use it, the "best" way to achieve something, and in searching for answers they'll stumble across a Babelesque bazaar of different responses, most of which don't go into detail but simply recap the more basic, core features org-mode has which every one uses, without mentioning the one or two features that might actually be revolutionary for that specific prospective user's workflow.
The result of this is that most people who use org-mode tend to assume it can only be used in one fairly rigid way – the sort of community-folklore way of using org-mode that's sort of developed as people with that workflow (including the authors) try to explain what org-mode is to others by example, and then those people adopt that workflow as rote because they're used to tools and systems with particular expected workflows – and if their desired workflow doesn't fit with that folklore org workflow, they assume that isn't a way org can be used and move onto some other system. For instance:
- Most people don't know that org links can be created to refer to, inserted in, and followed from, any file at all, not just org files, making things like Denote and Howm, the main claim to fame of which is allowing you to put their own custom link markup in any other markup file to link between things.
- Or that you can label org headings with GUIDs and allow any heading in your agenda directory to be a suggestion when completing GUID-based links, as well as setting up a capture template that prompts you for a file name in your agenda directory whenever you capture something new, allowing you to build a Zettelkasten note system where each note is in a separate file but can link to any other heading in any other note as easily as if it was in the same note file, and where GUID locations are stored in a database for easy retrieval, meaning org-roam is largely unnecessary unless you have a truly gigantic number of notes.
- Nobody seems to realize that with a simple regex modification, headings referred to only by tags or GUIDs, without actual titles at all, are possible in org, making EKG largely pointless.
- Similarly, nobody seems to realize that you can use the built in org publishing system for publishing blogs without needing to even write any new code, and RSS feeds with a 40 line function, so all those org static blog publishing systems are totally unnecessary.
All of this functionality is possible because, like Emacs, org-mode is less an application with a specific purpose and intended workflow, and more a whole system for doing a related set of tasks. Where Emacs is a system for manipulating rich text, structured data, file systems, and operating system processes interactively in a malleable runtime environment, org-mode is a system for creating and manipulating structured rich text hypertextual information and viewing and exporting it in various ways, interactively. (You can see why org-mode and Emacs are such a natural fit!) It doesn't have "a workflow" because what it offers instead is an extremely powerful general markup language for expressing highly structured hypertext information (both mainline content and metadata), a system for parsing, reading, arranging, and manipulating that structure, and a set of interfaces for that functionality. What you do with that, how you use it, is completely up to you. There are an infinite number of ways to use org-mode, and the difference between any given workflow in org-mode is just a difference of habit, mindset, and a little Emacs Lisp.
What's awesome about this is that tools for thought, systems for managing your thoughts and information, are at their best when they're monolithic, fully integrated into a single system just like your brain is so that you can easily create links and references and relationships between anything that you're thinking about or having to manage, easily able to flow between different styles of workflow and thinking regarding information management depending on what makes sense for the given thing you're grappling with or even how you're feeling that day, or how your workflow changes over time, without ever locking you into one thing. A general purpose information management system that is flexible enough to change with the context and change with you, and handle any kind of information management task you might need, will be infinitely more useful than a bunch of rigid silos, over a longer period of time.