Over this past weekend, Twitter discovered the problem that I have dedicated the past four years of my life to solving. Why don't lawyers and other non-coders use git?
I enjoyed reading this thoughtful essay, Jordan. Thanks for finally taking the time to share what you've been building and why with us.
Git never quite clicked for me. I could use it but it wasn't abstracted visually for me, which is a crutch I need. If you can make turn git into visual candy for lawyers that will be quite important.
At a larger level, your essay has me thinking about turning all bureaucratic document-based processes into gits. The room we leave for error is astonishing. Perhaps your second product can be Hill Hub, which is git for Congress.
It seems like you achieve a massive improvement just by having a single place where document versions are stored, and tracked. One of the most error prone processes is emailing documents that become out of date the moment sent.
Will you tackle making agreements that are written IN ALL CAPS READABLE next as well?!
I might be overlooking something, but if a firm is using O365 and can live-edit documents collaboratively, why is VS necessary? You can already track changes made by team specialists and consolidate all edits, then chuck the final mark up into Litera to generate a composite redline against the version sent by opposing counsel.
Thank you so much for writing this all up! This is clearly a more complicated problem than one would think from a quick glance.
I've been thinking about this a bunch for the last year or two. I initially started wondering why git for legal code didn't exist. So it's very exciting to see a working version. Your product appears to target law firms. My interests now lie at a broader level, wondering why agile workflows that are common in software development aren't applied when writing federal and state bills (the code of government).
When there's a bug or feature request, we start by nailing down the problem, and discussing the pros/cons of different solutions. We use GitHub issues and discussions for this. Once we come up with a solution we write test cases that ensure our solution will work under all possible conditions. We have automated tests for this. Only then do we implement a solution and propose it be adopted, which we do with merge requests. And then there's the the back and forth of code reviews. Additionally we use tools like Jira to visualize each step of this process. Why doesn't this exist for writing laws?
Your product fits well for the merge request and code review steps in this process. I'm currently very interested in building a product that covers all the steps leading up to that as I feel such a thing doesn't exist for legislation. It would be sweet if we could build something to cover the whole process and makes it easy for citizens to easily participate in government.
So I think this is a very good first step towards that vision. My hope would be that House and Senate bills eventually are visible to everyone as public merge requests. Your product might be the tool that allows that to happen.
It could be that your vision for the future is slightly different than mine, but it's so great to see others thinking along the same lines and working towards solving these common problems. I look forward to seeing this evolve and hope you have great success!
Thank you, Dan! Yes, our long term vision definitely encompass bringing concurrent version control to legislation. It's great to hear you're thinking about this as well!
Docx is WYSIWYG. It mixes two concerns, formatting and content, therefore it is unnecessary complex. Nevertheless, many users find it intuitive. Comparing unnecessary complex objects is at least one degree more complex.
Content should be first, and formatting only at the end (Latex et al). The paradigm lawyers use is flawed at the start, imho. Nevertheless, they are invested in this inconvenience and used to it.
Legal documents have a structure somewhat similar to scientific publications: paragraphs, chapters, footnotes and similar entities. They do not have arbitrary decorations on some pages, scented pages, artful perforations etc. This simplifies the problem a bit.
I wold try to solve this problem in this way:
1. Decompose the starting document(s), preferably to logical parts, separate statements. This is like a piece of code, consisting of statements. Laws are code for humans :)
2. Do the comparisons, editing etc. Use some database format as working format, like SQLite. It will increase the processing speed and decrease memory requirements.
3. Re-compose the document at the end, applying formatting according to one or more styles, export in whatever formats needed.
When dealing with our VAR, auditors, legal counsel, and other vendors, our CEO demanded that we get them to use a Google doc/sheet, rather than send 17 versions of a contract or BOM. It was hard to get them to adopt, but once they did, it really helped keep things sane. Having clear diffs between versions would have been an even bigger enhancement. Great idea!
neat! always nice to see someone just doing some thing you imagined at some point.
this will also help a lot for co-editing project proposals etc. the habit of endless email versioning is still prevalent there, albeit the final document not being as delicate as legal ones.
Love the breakdown but there’s already a solution. Google docs, MS word, etc. They come with editor tools. You can concurrently “track changes,” “suggest edits,” “accept/reject changes,” etc. On top of that, they come with full version control. You can revert back to previous auto saves.
I used to manage a team of financial writers. And I’ve also taken com sci courses over the years. It’s crossed my mind many times that these doc tools are similar to git :)
Maybe I’m missing some nuance and of course, still might be a great product (if better focus/UI). The tough part is getting legal teams to adjust existing workflows.
Either way, I’m intrigued. I’d be happy to share more thoughts and bounce ideas around. You can easily find my contact info online :)
Just read it and your other copied response before. I used to work at one of the largest financial newsletter publishers in the world. And some of our promo copy drafts would be 50+ pages. Sometimes 20 or 30+ people working on it (researchers, editors, copywriters, designers, marketers, legal reviewers, execs, etc.). You can adjust user access controls and timing.
Coauthoring like Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
A time saving tool for pay-per-hour professionals aren't always welcomed. I think this is another reason there is no dominant SaaS for this yet, it is hard to sell.
This is my intuition as well. at the same time, the layers can still remain in place, and in theory the time saved copy/pasting is taken up with actually doing the brain-thinking work.
It's like GenAI for sorting out syntax issues in code, dealing with syntax issues isn't where the money/value is created it is in actually finishing a feature and getting that into customers hands.
I solved much of this problem (diff/merge in nested xml or expanded markdow ) a decade ago with a novel algorithm, see https://github.com/imazen/suspension and the umbrella Repositext project. The goal was the same; git for non-technical users that had a Word/InDesign/XML/Lucene workflow. It has worked well.
Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
With zero modification this would also be indispensable for (conventional) engineers writing compliance documents
I enjoyed reading this thoughtful essay, Jordan. Thanks for finally taking the time to share what you've been building and why with us.
Git never quite clicked for me. I could use it but it wasn't abstracted visually for me, which is a crutch I need. If you can make turn git into visual candy for lawyers that will be quite important.
At a larger level, your essay has me thinking about turning all bureaucratic document-based processes into gits. The room we leave for error is astonishing. Perhaps your second product can be Hill Hub, which is git for Congress.
Thank you, Mike! Git for Congress is definitely part of the long term vision!
Very interesting!
It seems like you achieve a massive improvement just by having a single place where document versions are stored, and tracked. One of the most error prone processes is emailing documents that become out of date the moment sent.
Will you tackle making agreements that are written IN ALL CAPS READABLE next as well?!
I might be overlooking something, but if a firm is using O365 and can live-edit documents collaboratively, why is VS necessary? You can already track changes made by team specialists and consolidate all edits, then chuck the final mark up into Litera to generate a composite redline against the version sent by opposing counsel.
Great logic / love the mission - and see you have some early adopters which is awesome. Moving lawyers away from docx will be a big challenge..
Thanks Nick!
We actually have no intentions of moving lawyers away from docx! We've built our product to be fully compatible with the way they currently work.
Thank you so much for writing this all up! This is clearly a more complicated problem than one would think from a quick glance.
I've been thinking about this a bunch for the last year or two. I initially started wondering why git for legal code didn't exist. So it's very exciting to see a working version. Your product appears to target law firms. My interests now lie at a broader level, wondering why agile workflows that are common in software development aren't applied when writing federal and state bills (the code of government).
When there's a bug or feature request, we start by nailing down the problem, and discussing the pros/cons of different solutions. We use GitHub issues and discussions for this. Once we come up with a solution we write test cases that ensure our solution will work under all possible conditions. We have automated tests for this. Only then do we implement a solution and propose it be adopted, which we do with merge requests. And then there's the the back and forth of code reviews. Additionally we use tools like Jira to visualize each step of this process. Why doesn't this exist for writing laws?
Your product fits well for the merge request and code review steps in this process. I'm currently very interested in building a product that covers all the steps leading up to that as I feel such a thing doesn't exist for legislation. It would be sweet if we could build something to cover the whole process and makes it easy for citizens to easily participate in government.
So I think this is a very good first step towards that vision. My hope would be that House and Senate bills eventually are visible to everyone as public merge requests. Your product might be the tool that allows that to happen.
It could be that your vision for the future is slightly different than mine, but it's so great to see others thinking along the same lines and working towards solving these common problems. I look forward to seeing this evolve and hope you have great success!
Thank you, Dan! Yes, our long term vision definitely encompass bringing concurrent version control to legislation. It's great to hear you're thinking about this as well!
Docx is WYSIWYG. It mixes two concerns, formatting and content, therefore it is unnecessary complex. Nevertheless, many users find it intuitive. Comparing unnecessary complex objects is at least one degree more complex.
Content should be first, and formatting only at the end (Latex et al). The paradigm lawyers use is flawed at the start, imho. Nevertheless, they are invested in this inconvenience and used to it.
Legal documents have a structure somewhat similar to scientific publications: paragraphs, chapters, footnotes and similar entities. They do not have arbitrary decorations on some pages, scented pages, artful perforations etc. This simplifies the problem a bit.
I wold try to solve this problem in this way:
1. Decompose the starting document(s), preferably to logical parts, separate statements. This is like a piece of code, consisting of statements. Laws are code for humans :)
2. Do the comparisons, editing etc. Use some database format as working format, like SQLite. It will increase the processing speed and decrease memory requirements.
3. Re-compose the document at the end, applying formatting according to one or more styles, export in whatever formats needed.
When dealing with our VAR, auditors, legal counsel, and other vendors, our CEO demanded that we get them to use a Google doc/sheet, rather than send 17 versions of a contract or BOM. It was hard to get them to adopt, but once they did, it really helped keep things sane. Having clear diffs between versions would have been an even bigger enhancement. Great idea!
neat! always nice to see someone just doing some thing you imagined at some point.
this will also help a lot for co-editing project proposals etc. the habit of endless email versioning is still prevalent there, albeit the final document not being as delicate as legal ones.
are you gonna ipo at some point?
Love the breakdown but there’s already a solution. Google docs, MS word, etc. They come with editor tools. You can concurrently “track changes,” “suggest edits,” “accept/reject changes,” etc. On top of that, they come with full version control. You can revert back to previous auto saves.
I used to manage a team of financial writers. And I’ve also taken com sci courses over the years. It’s crossed my mind many times that these doc tools are similar to git :)
Maybe I’m missing some nuance and of course, still might be a great product (if better focus/UI). The tough part is getting legal teams to adjust existing workflows.
Either way, I’m intrigued. I’d be happy to share more thoughts and bounce ideas around. You can easily find my contact info online :)
For a more detailed elaboration on why coauthoring is insufficient, see this great article by Jack Shepherd.
https://jackwshepherd.medium.com/is-document-collaboration-in-law-firms-just-too-old-school-3371c024ddbf
Just read it and your other copied response before. I used to work at one of the largest financial newsletter publishers in the world. And some of our promo copy drafts would be 50+ pages. Sometimes 20 or 30+ people working on it (researchers, editors, copywriters, designers, marketers, legal reviewers, execs, etc.). You can adjust user access controls and timing.
Coauthoring like Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
A time saving tool for pay-per-hour professionals aren't always welcomed. I think this is another reason there is no dominant SaaS for this yet, it is hard to sell.
This is my intuition as well. at the same time, the layers can still remain in place, and in theory the time saved copy/pasting is taken up with actually doing the brain-thinking work.
It's like GenAI for sorting out syntax issues in code, dealing with syntax issues isn't where the money/value is created it is in actually finishing a feature and getting that into customers hands.
I solved much of this problem (diff/merge in nested xml or expanded markdow ) a decade ago with a novel algorithm, see https://github.com/imazen/suspension and the umbrella Repositext project. The goal was the same; git for non-technical users that had a Word/InDesign/XML/Lucene workflow. It has worked well.
Just tell the lawyers to do their drafting in Catala or LawDact and you can do semantic diffs rather than lexical ones! :)
"How do we know which rows from the original document match with which rows of the modified?"
https://react.dev/learn/rendering-lists#keeping-list-items-in-order-with-key:~:text=important%20if%20your%20array%20items%20can%20move
Tadaaaa!
Heard of google doc?
Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.