←back to thread

On Building Git for Lawyers

(jordanbryan.substack.com)
162 points jpbryan | 3 comments | 14 Nov 24 15:48 UTC | HN request time: 0.663s | source
Show context
mushufasa ◴[14 Nov 24 16:15 UTC] No.42137668[source]▶
I remember a post on here a few years ago about someone who had tried doing this and failed. I don't remember the details but you may be able to find it if you search well.

My recollection of his takeaway was that lawyers actually didn't want a lot of the things git offered. For example, they always wanted to be using the latest version -- the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked. And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.

replies(4): >>42137806 #>>42137963 #>>42138210 #>>42138335 #
1. jpbryan ◴[14 Nov 24 16:27 UTC] No.42137806[source]▶
> the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked

This depends a lot on the practice. Transactional lawyers working in M&A and real estate encounter the issue of parallel drafts all the time. Personal injury lawyers tend to work in isolation and don't need all of git's functionality. Pretty much every lawyer redlines in some capacity, however, and benefit from visualizing a linear version history.

>And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.

Yes, this is absolutely correct. This is one of the main things that keeps docx entrenched as the standard in legal collaboration. It would be an enormous faux-pas to send another lawyer a contract in an application that they're unfamiliar with. Backwards compatibility with their existing workflows is essential.

replies(1): >>42137930 #
2. 9dev ◴[14 Nov 24 16:37 UTC] No.42137930[source]▶
I don’t see how the network lock-in problem couldn’t be solved by automatically generating a DOCX version, however. As long as you can seamlessly import and export the standard—or shall we say, legacy?—format, you could work with a version control app without the other side even noticing.
replies(1): >>42142630 #
3. mushufasa ◴[14 Nov 24 23:57 UTC] No.42142630[source]▶
in theory yes.

in practice... google docs and libreoffice still have formating and vcs compatibility issues. To an amateur it looks fine because both systems claim to support docx and will open/write files. To someone who deals with a lot of documents... let's say it caused enough issues where it didn't pick up or properly delete microsoft word's proprietary track changes to where our lawyer just offered to personally buy me an official microsoft word license to avoid the back and forth. Actually, that was when i was already using the web-based microsoft365 word online! the codebase for desktop word must be deep deep spaghetti.

if you think you can solve what Google hasn't in 15 years despite many dedicated resources, or the entirety of the FOSS efforts over 30 years for libreoffice... that would be literally incredible