I would love to have you as a customer, but I'd have to do more research on what it would take to import the workflows and repository. If you're open to talking about this, my email is jake [at] commonpaper.com
713 karma · joined August 22, 2008
One guess is that it might be a relatively small community where the same people and companies do business with each other over and over. In a community like that, some of the jobs that contracts do in other industries might be done through norms and relationships.
I enjoyed "Why Trust Matters" by Ben Ho (https://www.amazon.com/Why-Trust-Matters-Economists-Guide/dp...) and it talked about a sweet spot where contracts shouldn't try to over or under-specify the deal in order to optimize for trust. I'm sure that some industries, like Hollywood, have less laid down in contracts than others.
If you're open to it, I'd love to hear more about how you've seen this work in Hollywood.
They can potentially help with configuring the standards for your business and/or drafting something custom if none of those are a fit
When lots of organizations use standard contracts, everyone becomes more efficient regardless of what tech they use (or even if they're just working with contracts manually). Standardization also enables us to build a different kind of software for managing contracts
We're also encouraged by the examples of standard contracts in other domains that have gotten traction with large enterprises. Basically all of the big banks use the ISDA master agreement^1 for financial derivatives, and the vast majority of ads sold on the internet use the IAB standard terms^2.
1 https://en.wikipedia.org/wiki/ISDA_Master_Agreement
2https://www.iab.com/wp-content/uploads/2015/06/IAB_4As-tsand...
Full details on pricing here: https://commonpaper.com/pricing/
Our target customers are B2B SaaS companies, and our goal is to have them start using us when they are small on the free version and grow with them.
I agree that the bigger entities are the hardest ones to get onboard with this, but our users have signed contracts with Fortune 500 companies and large universities, including deals for hundreds of thousands of dollars. It's actually in the cases where there's a big mismatch in size that we can provide the most help, although there are plenty of cases where the big company draws a hard line and won't use anything but their in-house contract.
> The process for creating and revising the contracts is modeled after an open-source software project Which Open Source Project? Could you link it please?
We didn't model it after a particular open-source project. Rather, we tried to take lessons learned from open-source software projects in general and apply those lessons to the creation and maintenance of the standard contracts.
> What do you mean by Open Source Contracts? Do you mean community edits & maintains contract templates?
There's a few elements of what we mean by this: - The contracts are released under the Creative Commons CC BY 4.0 license. It shares a lot of principals and goals with the OSI licenses for software (eg Apache and GPL) but is built for things other than software - Yes, the community edits and creates the agreements. The community members are largely attorneys rather than software developers, and you can see a list of some of the most active members here: https://commonpaper.com/committee/ - We have an amazing attorney on our team who is analogous to the maintainer of an open-source project. She solicits and collects feedback from the community and makes the final decision about what does and doesn't get into any particular release.
>Do you have APIs to integrate?
Yes, and you can see the docs here: https://api.commonpaper.com/docs
>Do you have your own way of signing contracts or use third party tools like DocuSign?
We embed Dropbox Sign (formerly HelloSign) within our product for this step
The difference is that the agreements are split up into cover pages, which are designed to be edited/negotiated for different companies and deals, and the standard terms, which are designed to be the same across uses of a particular agreement type.
As a simplified example, the standard terms included a section describing the limitation of liability. In that section, there's a variable for a "liability cap" which gets set on the cover page. The idea is that you might negotiate over whether that cap is $10,000, $1 million, or 2X the past 12 months' fees, but that you rarely need to negotiate the wording of the paragraph describing the limitation of liability.
All that being said, this won't work for every business or deal, but we do hope that it will work for an increasing percentage of them over time.
If both sides are arguing for their own custom template, then it's basically an arm wrestling match and whoever has the most leverage wins. If one side instead says "We adopted this independent standard created by attorneys from a bunch of companies" they get more leverage while being less adversarial.
Our early users saw a significant increase in the percentage of deals on their own paper (which is/was the standard) before they could be getting any benefit from the customer having seen the agreement before.
I expect that the agreements will just work for some countries, require minor changes for others, and in some cases need to be basically rewritten from scratch.
If you do take the agreements to a local attorney and find out what does and doesn't work in your country, we'd be really grateful if you shared that feedback. We've had a few people do that already, and it's helped in our plans for expanding into natively supporting other countries.
I've spoken with lots of lawyers in procurement at large companies. They're typically perceived as a cost center, and they often have to deal with lots of people from the rest of the business complaining that the contracts need to be reviewed/approved faster.
If they are processing thousands of vendor contracts per year, think about how much faster they can be if most/all of those contracts are on their in-house template, rather than a different template for each vendor.
But if lots of their vendors are using a standard contract, then there isn't the same cost in terms of time for using it.
All that said, this is going to be hard, and we're not expecting everyone to change overnight. We have, however, been encouraged to see examples of large companies signing the standard contracts, and we're grateful to have attorneys from big companies like Thompson Reuters and Salesforce on our committee.
For the Oracle example, big, old-school companies like this are definitely the hardest to get onboard. However, there are examples of large enterprises adopting standard contracts, including:
The biggest banks in the world trade derivatives using the ISDA master agreement (here's an example of Bank of America that they filed publicly: https://www.sec.gov/Archives/edgar/data/1065696/000119312511...)
The largest ad platforms and advertisers use the IAB standard terms, often with a short addition specific to their company (Here's an example from Disney https://disneyconnect.com/dpep/disney-ad-guidelines/)
We've already seen examples of Fortune 500 companies signing Common Paper agreements, and we're hopeful that it will become more and more accepted by them over time
You're totally right about all of the flavors DB2. Our support team would be the ones to figure out for sure whether or not we can work with your setup, and you reach them at support@stitchdata.com
I believe that the development of the scientific method and evidence-based decision making is the most important development in human history. It's not universal, and it's a lot of work. We want to motivate more people to come over that way of thinking and make it easier for them to do so.
www.stitchdata.com
A good beginner project is to build an adapter to a new data source (known as a "tap" in Singer). Most taps pull data out of business tools like Salesforce or Marketo, but people also build them to pull characters from the Marvel API (https://www.stitchdata.com/blog/tapping-marvel-api/)
Check out the getting started guide (https://github.com/singer-io/getting-started), or jump into the Singer Slack and ask for help (linked from the guide)
One of the amazing things about CBT is that instead of building up a tolerance, like you would with a sleep aid like Ambien, it gets more effective over time. It's self reinforcing, positive feedback loop.
My sleep isn't perfect, and I still take an Ambien every once in a while like on a red eye flight. However, if you're having trouble with sleep, I can't recommend CBT highly enough.
Sometimes it's funny, sometimes it's annoying. I can't recall ever having this issue with "Hey Siri" and I don't own a Google Home
I'd love to know which previous standards you're referring to, could you elaborate?
It's not as much a matter of open-sourcing the targets within Stitch because our functionality around data warehouse loading includes a lot of things like multi-tenancy, monitoring, and alerting that are necessary for running a SaaS service but not as relevant for a single organization's internal use.
In the meantime, our hope with the CSV target was that it would be a helpful intermediate step for getting data almost anywhere. Here's Google's documentation for loading CSV files into BigQuery: https://cloud.google.com/bigquery/loading-data#loading_csv_f...
That may not be the case with 100% of the community built/ maintained integrations, but our goal with the Singer Slack community and list serve is to connect people using these taps to so that they can validate which are working well and which need additional work.
ETL definitely existed before Singer and Stitch, however, and two of the most well known enterprise-focused products are Informatica and Talend.
The longer answer is that it may take us a while to get to 100% open source, but that's the direction we're moving. All of our new integration development will be open source and be part of the Singer project. Our original integrations were written in a different framework and couldn't be run independently of Stitch, and it's a nontrivial amount of work to convert them to the Singer format.
We included several of our existing integrations as part of this launch, and we'll definitely be adding more of them as well as new integrations.
Singer is an open-source standard for writing scripts that move data between databases, web APIs, files, queues, and just about anything else you can think of. Lots of companies build ETL scripts to move their data, and there's a huge amount of rework that happens from company to company. We believe that developers should spend less time moving their data and more time using it.
We're open sourcing 12 of our integrations (with more to come) so that they can be used in other applications, and we're excited to see what the community builds. Let me know if I can answer any questions.