* Khalid Rafi <[email protected]> [2025-12-12 16:21]: > > I am recently considering to use org-mode for contacts. But, I'm > thinking about its use cases. Does anyone use it? How does it benefit > you? One thing that concerns me is that how to integrate it with the > Android contacts app. If it were possible to automatically sync from org > contacts file to the Android contacts app or voce-versa, that would be a deal > breaker > for me. Is it possible?
Khalid, you’re not alone in wondering whether Org mode is the right tool for contacts. And yes — many do use it for contacts. But let’s be honest: they’re the ones who don’t have 244,268 people, 73,450 hyperdocuments, and 1,381 new hyperdocuments added last month. They’re the ones who don’t need to manage phone numbers that must conform to country-specific prefixes, with leading zeros stripped, international dialing codes validated, and relationships between people that span family, business, hierarchy, and ownership — all while maintaining referential integrity across 100+ related tables. Org lovers are biased. It is like for every case must be plain text solution. Sure. Even paper is a solution. But it is not scalable, and not feasible long term to manage it well. Org lovers will say, “It’s easily doable to keep contacts in Org.” They’ll show you a * Contacts * heading with a dozen #+BEGIN_BLOCK entries and :PROPERTIES: tags. But that’s just a toy. It’s not a system. It’s not a database. It’s not even a data structure that can scale. Org mode is fantastic for: - Writing notes - Tracking projects - Managing tasks - Building personal knowledge graphs - Writing agendas But it is not a relational database. It is not a type system. It is not a schema-aware data store. It’s a hierarchical text file with properties. And that’s it. People Are Complex ------------------ People are not flat lines of text. They are: - Entities with names, titles, departments, industries, and roles. - Related to other people — siblings, spouses, managers, clients, colleagues, mentors, rivals. - Linked to hyperdocuments, emails, locations, transactions, assets, schedules, and more. - Contacted via multiple channels — phone, email, SMS, VoIP — each with country-specific formatting, validation, and constraints. - Tagged with metadata — active/inactive, lead source, sales stage, priority, do-not-contact flags. Imagine dealing with 1000 or 244 thousands of contacts of people as I do. Org mode has no native way to: - Enforce that a phone number must conform to the country code and prefix rules (e.g., “+44 7911 123456” must not have leading zero or invalid country code). - Ensure that “John Doe” is not duplicated as “John Doe, Sr.” and “John Doe, Jr.” and “J.D. Doe” — unless you manually deduplicate them, which you won’t. - Maintain referential integrity when you delete a person — what happens to all the 127 tables that reference them? Do they cascade? Do they cascade with soft deletes? Do they cascade with notifications? - Handle relationships between people — “father of”, “business partner of”, “employee of”, “investor in”, “spouse of” — that are not stored as text in a description field, but as typed relationships with metadata. - Sync with Android contacts — because your Android contacts app doesn’t care about Org mode’s #+BEGIN_PROPERTIES, and Org mode doesn’t know how to generate VCards with proper RFC 2426 compliance, country codes, or dialing rules. Org mode is like trying to use a pen-and-paper notebook to manage a multinational corporation. Sure, you can scribble down “John Doe — CEO — 555-123-4567 — USA — active — sales stage: hot lead — related to Jane Smith — married — father of 3 — owns 12 companies — don’t call after 8PM — email: [email protected] — tag: hot, executive, active”. But what happens when you: - Try to search for all people with “father” relationship? - Try to export all active people with phone numbers in Germany? - Try to sync with your Android contacts app? - Try to generate a report: “List of all people with no phone numbers and no email”? - Try to auto-generate a VCard for import into Android? You’ll need to write 100 lines of custom Org mode macros. You’ll need to write a parser. You’ll need to write a validator. You’ll need to write a sync tool. You’ll need to write a deduplicator. You’ll need to write a backup system. You’ll need to write a migration system. You’ll need to write a UI to edit it. You’ll need to write a way to share it. You’ll need to write a way to export it. You’ll need to write a way to import it. You’ll need to write a way to audit it. You’ll need to write a way to version it. And then you’ll realize — you’re building your own CRM. You wish to be using Org mode for contacts because you’re thinking. And thinking is good. But you’re not thinking about data structure. You’re thinking about user experience and consistency. And for that, you need a dedicated application — a CRM, an address book, a people graph engine — that understands: - Data types — phone numbers, email addresses, countries, prefixes, time zones, languages. - Constraints — phone numbers must conform to country rules, email addresses must be valid, relationships must be typed. - Validation — built-in validation, auto-correction, auto-formatting. - Sync — with Android, iOS, web, desktop, cloud. - Search — full-text, fuzzy, semantic, relational. - Audit — who modified what, when, why. - Export/Import — in standard formats (VCARD, CSV, JSON, XML). - API — so you can integrate it with your existing systems (e.g., your database, your email, your calendar, your chat tools). You’re not using Org mode because it’s “flexible”. You’re using it because you’re thinking. But thinking doesn’t mean building a system. Org mode is not for contacts — not at scale. Not for people with relationships. Not for phone numbers with country codes. Not for data that must conform to rules. Not for data that must be synced with Android. Not for data that must be exported to VCard. Not for data that must be imported from VCard. Not for data that must be searched. Not for data that must be validated. Not for data that must be audited. Not for data that must be versioned. Not for data that must be backed up. Not for data that must be migrated. You need a system — a CRM — a people graph engine — a dedicated application — that understands data types, constraints, validation, sync, search, audit, export, import, API, UI, versioning, backup, migration. -- By Jean Louis — for the Org mailing list, with love for truth, not hype
