My Co-Founder and I are open sourcing digital signatures and taking on the $B-DocuSign-empire AMA

@peer_rich Personally I always found signatures and cryptography and the implications for business and society interesting. Not many do, as I learned recently :D From SSL to Bitcoin cryptography enables fundamental forces in the world, no matter where you stand. From a business perspective, I always found the idea of building and selling a nicely designed signing tool neat, but since the market is so full I never thought it a good Idea. It's a huge market, that is extremely growing, but also quite crowded. COSS (Commercial Open Source) changed my view on that. We see companies like DocuSign that have been around forever delivering mediocre UX considering their Budget. We also see companies and teams building signing tools from scratch again and again because there is nothing to build upon. This is mainly what triggered me: There are open ecosystems for almost any relevant technology but not signing, which literally every company does. It's a considerable chance to reshape a very closed industry into what it was actually meant to be: public, open trust infrastructure.

@julien_fayad Hi Julien, great questions, let me try to answer them briefly enough :) First of all yes, signing is often part of something bigger, be it a system or a workflow. We want Documenso to reflect that, since in my opinion it's one of the current pain points. - Complex workflow are on our roadmap and the goal is to support them natively in the plattform, better than anyone else at some point, since we should have the product learnings - Until we have native worklfow a very shortterm goal is to offer an open api, that you can easily integrate. This wil come together with widgets you can easilliy adapt to your case so you can integreate Documenso and built upon it pretty deeply - If you want to do the above using your own instance or ours is up to you, so far I don't foresee any fundamental technical differences. What's different is the data control, compliance, and support workflow of course, that's why it's up to you. If you are not into DevOps and rather focus on just integrating we'd be happy to host for you. Could be a dedicated version too maybe :) ---- As I'm a geek too, I'm happy you asked: - We use NextJS and PostgreSQL with Prisma. The UI is tailwind, some npm components, and the signing is another OSS library. We are planning to create UI and signing libraries of our own in due time (so there are finally some high-quality OSS assets everyone can use) - Security is quite complex. One of our core values is that by opening as many eyes as possible on everything we ensure nothing gets overlooked, be it small or fundamental architecture. Our goal is to have all kinds of experts in the community, ensuring we implement state-of-the-art best practices in every area. Allowing users to self-host critical cases is another pillar. Of course, there are many more points, but it's hard to generalize. Feel free to ask though, these things should be discussed openly so companies do less non-best-practice. - The Data of our soon-to-be Production Environment will lie in Frankfurt, Germany on render.com. Dedicated instances could be hosted somewhere else if necessary. Depending on the need of the community we are thinking about multiple security layers around the data like E2E encryption, though we want to validate the need first since it adds complexity. No uploading Documents to sign at all is also an interesting approach we are considering (signed in the browser). Here it will be a tradeoff on how much of a workflow we can offer without touching documents. If you made it through at least half, I'm pretty happy :)

@timur_ercan1 Thanks for the detailed answers. I hope there will be some GraphQL API ;-) As to run it on premise, will you ship a docker image with it ? I've been looking for a cool and customizable OS signing tool to integrate with custom processes to use for sales but also for projects deliveries, internal validation etc... and paying for each signature wasn't making sense to us. Your product, given it is secure and flexible enough, could be a great option on the table. Kudos

@julien_fayad Great to hear. This is exactly what we want to offer. Paying per signature makes my skin crawl. It's a relict the industry today does because they can and I love to break this. In some cases, we will need more time because of regulations but we will get there. For sales, it should be not that complicated though. We are pretty ready to use with docker and will be offering a ready-to-use image soon. Give a bit of docker know-how one could easily do it now I think. Not a big fan of GraphQL so far I'm afraid :D But I haven't used it much either and since we are open to being extended much is possible :) Let me know anytime you want to talk enterprise: https://cal.com/timurercan/enter...

@lxunos @fmerian Very naturally actually. I learned about Lucas, when he did a very zen live review of the cal.com repo on his Twitch channel and I thought I have to get one of those for Documenso. After that, he joined the community and contributed a bit which escalated to becoming Co-Founder pretty fast since he also is very much into open code. He happens to be a decent coder also :D

@thilokonzok They could as well have. Since I consider open source to be the future this was inevitable and @lxunos and I just happened to be the ones to do it. Some other factors may be: - Beeing developed by for-profit companies, previous software on this topic mostly stayed proprietary - The Industry considers the signing part hard, and the UI part easy, thus the mindset is, if you need a UI just build it - Most people consider signing rather boring (not me :D), thus it's not the space for the hot new killer app. Documenso will be the exception though ;) - One last big pain point is, that great design is really hard to do OSS, since it often relies on the vision of a single, great designer, which is initially kinda contrary to the everyone contributing spirit of OSS. Will be tricky to balance this, but we'll manage :)

@astrosaurus Not an easy question, though a very important one. Getting more than one person involved in a software project is always tricky, let alone tens or hundreds. While there is no exact plan yet, there are some values, that are definitely set. - We value all inputs of the community and discuss them intellectually honestly to find the best solutions to challenges. Technical and non-technical - We value and celebrate contributions, no matter the outcome - We share progress and goals openly with the community to get dynamic feedback and perspectives on issues - We actively work to accommodate the goals of what the community wants to achieve with Documesno since Documenso is a project of the people Adhering to these values would make me pretty confident we can't go too wrong. On the more pragmatic side, these would be some key points, regarding how I envision the work with the community (needless to say Lucas will have some great ideas on this matter too): - I will communicate the Vision and the current milestone as clearly as I possibly can, so everyone knows where we are and what is valuable - There will be a core team at Documenso Inc. working on a fixed roadmap to ensure progress and design a consistent project architecture - There will be a currently active release with required issues and nice to have issues - We will have continously evolving pools of issues for "good first issue" for newcomers, "exploration wanted" for topics we want to explore, and "help wanted" for stuff that needs to get done and exceeds our capacities - Bugfixes will of course always be welcome (not as trivial as it sounds, but an important cultural aspect IMO) -The coming App Store and API will empower devs to work more autonomously with the core team, allowing for more stuff to be created without taking other capacities While this sounds great even to me, it's of course easier said than done. Way easier. This is why the first part is actually more important than the second IMO. We can always fail on a process level (and then change it) but if we get the spirit and the values right that's just the noise of the machine working. Again, easier said than done, though I am starting to really like the current community vibe, so we are on a good way :)

@mfts0 Really hard to say, great thought piece though. My initial thought would be being the "WordPress of Signing" meaning being everywhere as the industry default for most cases, changing the question from "Why Documenso?" to "Why not Documenso?". Of course, the metaphor lacks since WordPress is not very specialized and Documenso will be fine-tuned for everything signing, but you get the point I think. Also, extendability should be the same. Personally, I love the idea of becoming the "PHP" of signing, refusing to die after decades :D Another big opportunity is to bring modern and beautiful software into areas, that hardly have access to modern developments like highly regulated industries e.g. healthcare or public administration

@mfts0 What excites me most I think is the aspect of becoming the go-to tech ecosystem for signing and bringing openness to the space as cliche as that sounds. Every time I look for information on signing-related topics I realized how closed this space is. Everyone is clinging to their bit of knowledge and is trying to sell it to gain an edge. Back when I founded my first Company I had to buy a SSL cert for like $150 since Let's Encrypt wasn't around. This still bothers me and we have the same thing today for signing. Basic signatures for many cases can be done without special certificates, but if we want to create an open, high-trust signing economy I think we need more access to high-security certificates. And right now they are being sold for horrendous prices by CAs (Certificates Authorities) just because they can. If Documenso can break this up by creating a Let's Sign, basically offering this for free, (analogous to Let's Encrypt), the opportunity is to break open the whole market and have everyone compete on Usability, UX, and Design. Something the signing industry has not put a great emphasis on so far, to be honest. And it's a shame since everyone needs signatures.

@flxmgdnz Looks like, playtime is over :D Just kidding, it is of course an interesting point. TL;DR; At the start partially, middle term completely. Naturally, Documenso is compliant, just not at every level, though full compliance is of course on the roadmap. How fast will be determined by market demand. Since most of the world does not abide by eIDAS. Our current Release 0.9 will support the eIDAS levels as follows Level 1 - Simple Electronic Signature (SES) - Full Compliance Level 2 - Advanced electronic signatures (AdES) - Partially Compliant: - We do employ actual signing using our own certificate since we did not want Documenso to be yet another PDF-Image-Editor - Our signing algorithm differs from the eIDAS standard, making us an n "Indeterminate AdES digital signature" like DocuSign and Digitsigner for example, since we did not go exactly by the DSS - Digital Signature Service reference implementation - Also we do not yet employ the dedicated signing hardware (HSM Hardware Security Modules) and audits required handling certificates of this level issues by QTSP (Qualified Trust Service Providers) Level 3 Qualified Electronic Signature (QES) - Not compliant Some main points why we can't offer QES yet are: - Identification: We need to validate the signer's identity via Passport or similar via camera - Again, no dedicated hardware and audits It is important to note, that while we only support Level 2 partially so far, this is on par with what e.g. DocuSign plans short of enterprise offer, since they also only offer SES. Many people don't know this and assume they are more compliant. Since eIDAS makes the jump from Level 1 to 2 so hard, a lot of services don't bother beeing compliant in my opinion. This is a shame since an actual signature at least ensures for example that the document has not been changed. Recognizing there is a lot to be done, even if not being fully compliant to Level 2 is why we decided to go this route. We as a company can certainly offer products of this category to enterprise customers by working with partners, which we will, given there is demand. But long term, we want the Documenso ecosystem to be independent of existing industry structures to not inherit the limitations on signing products, as they exist today. E.g. no easy way to highly secure mass sign without paying per signature. One more interesting thing I want to note is that the green checkmark shown by Adobe PDF is not actually driven by eIDAS compliance but Adobe Trust Liste compliance, which is at the discretion of Adobe. In my humble opinion, the green checkmark carries the most weight currently, if you do not have any requirements by law. As you can see, there is a lot of transparency and arbitrariness in the whole structure. Beeing open about all of it, I hope we can shed some dearly needed light and maybe bring some change eventually. Since it's such a complex topic, I will soon write more on this and our plans to position ourselves. Issuing actually eIDAS complaints signatures is way too hard to become the norm and we have some ideas to change that :) Edit: Format Edit: TL;DR; Edit: Checkmark Importance