Managing Legal Document Complexity With Software Development Tools
Abe Voelker recently authored a thought-provoking blog post on how version control systems used by software developers could potentially be used to rework the process of drafting legislation:
Imagine a public system like GitHub but instead of source code being tracked, legal documents such as bills/laws are tracked (and just like GitHub, versioned in git). Imagine if, before any bill is introduced to Congress, its contents were posted on this publicly available medium with adequate time before a vote?
What if any proposed amendments to legislation were posted publicly as pull requests?
What if anyone could write amendments to existing laws, or even entirely new laws and propose them to Congress (or lobby their Congressperson to introduce it) using pull requests?
What if you could fire up
git blame, and see who is responsible for writing each individual line of a bill? Think of how easy it would be to track down those pork barrelers (or worse), especially if the actual writer of the bill was tracked, and not just the bill’s congressional sponsor (grr… lobbyists).
The idea of taking versioning tools for software, one of the most complex realms of human endeavour, and applying those concepts to legal documents, a similarly complex pursuit, is a promising one. However, as Ari Hershowitz points out on a related Quora thread, the idea may be a non-starter because of simple demographics:
So what’s GitHub?
GitHub bills its platform as one that facilitates “social coding.” Rather than working in relative isolation, software developers can easily collaborate on projects, working in parallel and synchronizing their work via GitHub. Since software code is simply a type of document, the differences between two versions of a document can be viewed in a “diff”:
In this diff, new text is green, and deleted text is red. Although in this case the diff is of software source code, Mr. Voelker proposes the basic concept could be extended to the legal space, hopefully offering up a new level of transparency – and accountability – to the law-making process.
In the coming years, I have no doubt we’ll start to see individuals that straddle the legal and software development disciplines bringing ideas like this to realization. In a recent interview with Forbes, Chris Wanstrath, GitHub’s co-founder and CEO, concludes with a similar vision of software development extending beyond its traditional boundaries:
What we’ll see in the future is more people who aren’t programmers learning to code. Authors, lawyers, bankers – all kinds of people who don’t write code for a living will learn how to. They’ll automate repetitive tasks and build their own apps.
Jack– Very good argument here. As a former coder, now lawyer, it would be great to see a documented revision history for legislation. This concept could also be translated into brief-writing and contract drafting, too. One of the biggest shortcomings of new cloud-based word processing tools like Google Docs is its lack of versioning and ‘track changes’ features.
Thanks for this interesting post. David Moore suggests that the GitLaw approach could be promising for eparticipation services such as OpenCongress: Yes, let’s stride towards an open VCS for legislation (or, GitHub for laws on OC) http://www.opencongress.org/articles/view/2496-Yes-let-s-stride-towards-an-open-VCS-for-legislation-or-GitHub-for-laws-on-OC- . My comment on Voelker is here: https://plus.google.com/u/0/114505145191947983330/posts/UCWErphYduT
The U.S. House of Representatives’ Appropriations Committee last week ordered the formation of a task force to consider non-XML metadata standards for U.S. federal legislative data: http://legalinformatics.wordpress.com/2012/06/01/house-committee-votes-to-indefinitely-delay-public-bulk-access-to-u-s-federal-legislative-data/ . This may be an opportunity for advocates of GitLaw to persuade Congress to adopt their approach.
As a former lawyer and current software developer, I take issue with that Venn diagram! As a lawyer, I created all of my documents in XeTeX and stored them in a Git repository, then pushed the documents to my private GitHub account.
I think the biggest hurdle for lawyers who would like to use version control is the reliance on word processors and binary file formats. Microsoft Word documents don’t work well in a VCS. Plain text documents, on the other hand, are perfect for a VCS and offer many other advantages as well (no vendor lock-in, viewable on any platform, easily manipulated by other software programs to enable automation, separating content from presentation). But I do not expect lawyers to switch to XeTeX or Markdown or another plain text markup any time soon.
Larry, if you look closely enough there is a tiny speck in the union of the Venn diagram labelled “Larry Staton Jr. :-)
I agree that documents would have to be in a plain text format, like source code, to be managed effectively via a DCS, but I agree this will likely never see adoption among lawyers. The complexities of managing formatting of the documents would also present many challenges – as you point out, you’d be versioning both content and presentation, a challenge you don’t have with source code.
Thanks for commenting.