New Series Seed legal forms now in Markdown on Github
github.com
github.com
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.
Look for that to change as more firms move to fixed fee work.
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.
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.
First, in the legal sector, anything "cloud" is a total no-go. Handing confidential legal documents over to a third party creates a rats nest of privilege issues.
Second, many businesses don't depend on Word's track changes. There are tools for doing version control and diff-ing on Word documents. We e-mail around diffs (redlines) just like how the Linux kernel was managed back before git. What's missing is a "patch" replacement--hence handing markups to secretaries.
Third, Word compatibility is a huge advantage. Legal documents don't need anything too fancy (that said, Google Docs is extremely primitive so I'm not sure it can even handle everything legal documents need, particularly in the area of footnoting), but at the same time law firms have built up huge bodies of templates and precedent in Word format. Having to round-trip through Google docs to copy some language or a citation from precedent would be a huge pain in the ass. Also, there are lots of little plugins, macros, etc, that we use. Westlaw integration, for example, custom macros for generating boiler-plate, etc.
Fourth, clients all use Word, and they all send redlines around too. You hand Goldman Sachs a Google Doc link, and they'd be like "what is this shit?" Big companies have exactly the same set of things tying them to word. Goldman has worked on a billion different prospectus statements before, and they're all in Word format. So you have to have Word and all those tools around anyway for documents coming in and going out.
Fifth, Google Docs sucks. It's the only Office Suite that's even more awkward and finicky than MS Office, and that's saying a lot. I hate using it for the most basic things--I'd hate to have to use it at work. Word processing has been pretty much downhill since Word Perfect 6.x, but it's really hit a new low with Google Docs.
So maybe Google Docs isn't the best option currently, but there are definitely more efficient ways to work than what is done now. This is an area that could use some innovation, and putting things on github is an early step to find out what can work. However, those who are used to status quo have to be interested in finding new, perhaps better, ways to work. If you go into things thinking you're married to Microsoft Office, nothing is going to change.
There is nothing better right now than the MS Word workflow with all the accumulated templates, macros, etc. We can both imagine better things, and it is indeed an area that could use a lot of innovation, but github, with zero support for word processing formats or even binary files in general, is a non-starter here. Want to disrupt the space? Make Github for ODF documents in a way that let's you cleanly e-mail around diffs and apply them, and let's you easily merge changes from multiple people to documents that may have drifted from the branch point. Make it robust, so people don't fear using the tool for what it might do to their documents. That's a billion dollar Office monopoly-challenging idea right there with applications far beyond the legal space. It's also technically challenging as hell. This is not a space where a minimally viable product is going to play. It's competing with MS on its own turf.
That's a fine suggestion for a product, and you're right about it competing with MS on its own turf: and that's why no one will use it. There is nothing super inherent with many documents that are currently emailed around as whole atomic units that they wouldn't be better represented as plain text. And git ALREADY handles plain text really well. It handles emailing diffs and applying changes from email. It is robust enough to not cause fear of using the tool for with it might do to the text. People are married their MS Office based workflow, and they will always find an excuse to maintain it. Migrating the individual components to a different platform (MS Office to ODF) is a valid way to challenge the status quo, and it's just as valid to challenge it by revisiting the assumptions that enforce the status quo (that you need to email diffs or documents around, for example; that can be challenged with on-line, simultaneous, collaborative editing -- which removes the need to email diffs around). Neither one is going to make significant inroads against the current momentum, no matter which of the finer points of momentum (popularity, network effects, cost of transition) can be resolved.
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'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?
It is time that the legal profession joined the 21st century and automates that which can be automated.
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: