The existing paradigm is to pay associates $300/hr to pass redlined word documents back and forth or markup docs by hand during phone calls / meetings and then give the hand marked up docs to legal assistants to input changes.
Inevitably things get lost in translation and it's difficult to figure out why things changed versions ago. It's also very expensive.
The resistance to change is driven by the fact that the majority of lawyers make a lot of money being inefficient.
I'm guessing github is not the preferred interface for lawyers but it could very well be the engine behind a more "lawyer friendly" interface.
Great to see the seeds of change being sewn, anyways.
Lawyers don't use Github for documents for the same reason nobody else uses Github for documents. Corporate America's workflow is based on Word/Excel/etc. There's no good Github-like service for Word/Excel/etc that's appreciably better than passing redlined documents back and forth. There is a business opportunity here for an enterprising engineer... And while you're at it, how about something that's better for marking up documents than a print out and a red pen?
Your comments refuting this are well taken and in hindsight my comment above was cynical and lazy...probably somewhat due to recently paying an enormous legal bill.
Considering the amount of changes, and the terrible interface that Word has for viewing history/tracking changes, Google Docs is perfect for making these kinds of edits, reviewing history and tracking changes. To top it off, legal documents have none of the "requirements" of the "extra features" that people normally complain about when it comes to why they can't stop using Microsoft Office products.
They could still print them out, red-line them by hand, and keep legal assistants employed who update the canonical on-line version.
I've received attachments from someone sent to multiple people with instructions of "make your changes and send it back to me". And then the sender spends time manually merging people's changes into a single document. What a waste.
The amount of effort and time saved in not having to keep track of the most recent version from the multitude of revisions that litter your inbox as attachments and which one is/should be considered canonical would more than make up for any other perceived drawback.
It's purely momentum that keeps MS Office entrenched in this area.
Funny, just earlier today I happened to watch a Clay Shirky TED talk ("How the Internet will Transform Government"), where he showed a hilarious screenshot: a Venn diagram of Lawyers and People with Github accounts.[0]
0. http://25.media.tumblr.com/tumblr_mbkedsQ3EZ1qaxovpo1_500.jp...
I converted a group of lawyers, who were still using Corel Wordperfect for drafting multistate legislation, to using an XML based workflow, after showing them why it would make them faster, not why it was "better for the world who was trying to look at drafts".
Imagine you used emacs all day, every day, and then someone came in and says "we're all moving to VIM".
Personally, I do all my drafting in text and use version control, but use word as an interchange format when stuff goes outside of the company.
I think many startups (including one of my own) fail because they underestimate the difficulty of changing people's workflow.
Look for that to change as more firms move to fixed fee work.
I've recently started to do this for technology Statements of Work in government. If City A writes a Statement of Work for a Wordpress integration, why should City B have to write the same thing?
One question. I understand that the set of items in these documents is carefully chosen based on many years of experience and thousands of data points. A lawyer could probably take a look at this and understand it in 10 minutes.
But for a non lawyer, it seems like too much too soon. I have to figure most companies will need very few of these provisions.
Is there a way to structure this type of document so that the most important thing(s) only could be included, perhaps on one page?
And then structure it in such a way that every few months, or few years, you add a "plugin" for your particular company needs?
My problem with these types of documents is that for 2 guys in a garage they seem to be overkill, and it would be nicer if there were a simpler option that starts with a tiny core that you can then add on as you go.
Regarding the "plug in" process you mention, that's actually a good analogy for what happens between these docs, which are used in a seed round, and the larger set of docs that are used in a next round like a Series A. Believe it or not, these Series Seed docs are significantly stripped down from what Series A docs look like.
Not sure if that entirely answers your question or not, but let me know if there's anything I can help out with.
That does answer my question. I guess for me, I see these documents and I am overwhelmed. But that's just probably because it's so foreign to me.
I actually was going to say, is there anyway to make these documents more concise like underscore.js? Then I opened up underscore.js in Textmate, hit print, and realized it would be 30 pages printed.
I guess I didn't realize how much the perceived length of something depends on the background of the reader. For me, underscore.js is small and concise, for a non programmer it probably looks like a tome. When I saw the Seed docs to me it was a tome, but to you it's probably a quick read.
I do wish legal docs were smaller. But I also wish code were smaller. And I don't really have an answer to how to make that so!
After a while, if/when 'market convention' drifts such that everyone is overriding definitions in the same way, a new 'Definitions' document is created, and people start to work off that.
Markdown extensions for inline change-indications may be part of the puzzle as well:
It is time that the legal profession joined the 21st century and automates that which can be automated.
