On Building Git for Lawyers
Efforts to build “Git for lawyers” aim to bring robust version control and branching concepts to complex legal documents without dislodging Microsoft Word and .docx, which remain entrenched due to formatting quirks and the need for seamless exchange with counterparties. Commenters debate whether lawyers actually want or need developer-style tools, pointing to Word’s track changes, document management systems, risk-averse firm cultures, and billable-hour incentives versus the clear pain of messy redlines, parallel drafts, and error‑prone manual merges. Many see potential for similar tools in adjacent fields like finance, engineering, and legislation, but stress that success hinges on invisible backends, simple UX, and strict backward compatibility with existing workflows.
Perceived Need for “Git for Lawyers”
- Many lawyers and ex-lawyers report painful experiences tracking changes in large contracts, especially with multiple parties and adversarial counterparts.
- Problems cited: parallel drafts, hidden or undisclosed changes, manual merge errors, difficulty seeing a clean delta, and slow handling of big documents.
- Some engineers and clients reviewing legal docs also find Word-based workflows miserable and wish for clearer, linear history and better review UX.
Why DOCX and Word Remain Dominant
- Strong network lock‑in: everyone else expects DOCX with Word’s tracked changes; sending anything else is seen as unprofessional.
- Previous attempts requiring counterparties to join a new platform failed because onboarding “the other side” is too high a barrier.
- Backward compatibility with existing Word-centric workflows is viewed as essential; some tools position themselves as working even if only one side uses them.
Views on Word’s Track Changes and Versioning
- Critics: slow on large docs, noisy diffs (especially formatting and renumbering), fragmented history across files, and risk of leaking internal comments.
- Defenders (including experienced lawyers): Word’s tools are “good enough,” support legally meaningful formatting/citations, and the marginal benefit of new tools rarely justifies cost and training.
- Several note that proper use (e.g., cross-references, document-scrubbing tools) is underutilized but mitigates some issues.
User Needs vs Developer Mindset
- Repeated theme: developers over‑design programmer-style solutions (branches, Git UIs, LaTeX, DSLs, formal verification) that don’t match how lawyers work.
- Users often want a “toaster”: simple UI, minimal concepts, seamless integration into existing habits.
- There is debate over whether users mis-specify their own needs or whether developers fail at requirements gathering; most agree communication is hard.
Adoption Barriers and Incentives in Law
- Cultural inertia: law firms are conservative, some partners still work on paper; moving from WordPerfect to Word was already hard.
- Business model issues: menial document work trains juniors and is billable; some argue reducing it is not always in firms’ short‑term interest, others counter that error reduction and capacity gains still matter.
- A counter‑trend is noted: younger, more tech‑friendly partners and rising legal‑tech budgets.
Alternatives and Technical Approaches
- Suggestions: custom diff engines over DOCX, exporting/importing clean Word redlines, Git backends with text-conversion filters, or new VCS backends like jj.
- Skepticism that anyone can fully solve DOCX compatibility given long‑standing issues even for Google Docs and LibreOffice.
- Some argue truly robust solutions require deeply understanding and re‑implementing Word’s behavior, a very hard engineering problem.
“Git for X” Beyond Law
- Similar versioning pain reported in finance, engineering specs, construction change orders, medical device documentation, and personal note‑taking.
- Many commenters doubt Git’s CLI model will ever be widely adopted outside tech; domain‑specific, highly simplified UIs on top of version control are seen as more plausible.