diff --git a/.env.example b/.env.example index d188894de..c482c128e 100644 --- a/.env.example +++ b/.env.example @@ -4,8 +4,10 @@ NEXTAUTH_SECRET="secret" # [[CRYPTO]] # Application Key for symmetric encryption and decryption -# This should be a random string of at least 32 characters +# REQUIRED: This should be a random string of at least 32 characters NEXT_PRIVATE_ENCRYPTION_KEY="CAFEBABE" +# REQUIRED: This should be a random string of at least 32 characters +NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY="DEADBEEF" # [[AUTH OPTIONAL]] NEXT_PRIVATE_GOOGLE_CLIENT_ID="" @@ -23,7 +25,7 @@ NEXT_PRIVATE_DIRECT_DATABASE_URL="postgres://documenso:password@127.0.0.1:54320/ # [[E2E Tests]] E2E_TEST_AUTHENTICATE_USERNAME="Test User" E2E_TEST_AUTHENTICATE_USER_EMAIL="testuser@mail.com" -E2E_TEST_AUTHENTICATE_USER_PASSWORD="test_password" +E2E_TEST_AUTHENTICATE_USER_PASSWORD="test_Password123" # [[STORAGE]] # OPTIONAL: Defines the storage transport to use. Available options: database (default) | s3 @@ -72,6 +74,8 @@ NEXT_PRIVATE_MAILCHANNELS_DKIM_DOMAIN= NEXT_PRIVATE_MAILCHANNELS_DKIM_SELECTOR= # OPTIONAL: The private key to use for DKIM signing. NEXT_PRIVATE_MAILCHANNELS_DKIM_PRIVATE_KEY= +# OPTIONAL: Displays the maximum document upload limit to the user in MBs +NEXT_PUBLIC_DOCUMENT_SIZE_UPLOAD_LIMIT=5 # [[STRIPE]] NEXT_PRIVATE_STRIPE_API_KEY= diff --git a/.github/ISSUE_TEMPLATE/feature-request.yml b/.github/ISSUE_TEMPLATE/feature-request.yml index ab21e8828..ffb788c23 100644 --- a/.github/ISSUE_TEMPLATE/feature-request.yml +++ b/.github/ISSUE_TEMPLATE/feature-request.yml @@ -33,3 +33,4 @@ body: - label: I have explained the use case or scenario for this feature. - label: I have included any relevant technical details or design suggestions. - label: I understand that this is a suggestion and that there is no guarantee of implementation. + - label: I want to work on creating a PR for this issue if approved diff --git a/.github/ISSUE_TEMPLATE/improvement.yml b/.github/ISSUE_TEMPLATE/improvement.yml index 058a025e7..de2983b67 100644 --- a/.github/ISSUE_TEMPLATE/improvement.yml +++ b/.github/ISSUE_TEMPLATE/improvement.yml @@ -1,35 +1,39 @@ -name: 'General Improvement' -description: Suggest a minor enhancement or improvement for this project +name: 'General Improvement Request' +description: 'Suggest a minor enhancement or improvement for this project' +title: '[Title for your improvement suggestion]' body: - - type: markdown - attributes: - value: Please provide a clear and concise title for your improvement suggestion - type: textarea attributes: - label: Improvement Description - description: Describe the improvement you are suggesting in detail. Explain what specific aspect of the project it addresses or enhances. + label: 'Describe the improvement you are suggesting in detail' + description: 'Explain why this improvement would be beneficial. Share any context, pain points, or reasons for suggesting this change.' + validations: + required: true - type: textarea + id: description attributes: - label: Rationale - description: Explain why this improvement would be beneficial. Share any context, pain points, or reasons for suggesting this change. - - type: textarea + label: 'Additional Information & Alternatives (optional)' + description: 'Are there any additional context or information that might be relevant to the improvement suggestion.' + validations: + required: false + - type: dropdown + id: assignee attributes: - label: Proposed Solution - description: If you have a suggestion for how this improvement could be implemented, describe it here. Include any technical details, design suggestions, or other relevant information. - - type: textarea - attributes: - label: Alternatives (optional) - description: Are there any alternative approaches to achieve the same improvement? Describe other ways to address the issue or enhance the project. - - type: textarea - attributes: - label: Additional Context - description: Add any additional context or information that might be relevant to the improvement suggestion. + label: 'Do you want to work on this improvement?' + multiple: false + options: + - 'No' + - 'Yes' + default: 0 + validations: + required: true - type: checkboxes attributes: - label: Please check the boxes that apply to this improvement suggestion. + label: 'Please check the boxes that apply to this improvement suggestion.' options: - - label: I have searched the existing issues and improvement suggestions to avoid duplication. - - label: I have provided a clear description of the improvement being suggested. - - label: I have explained the rationale behind this improvement. - - label: I have included any relevant technical details or design suggestions. - - label: I understand that this is a suggestion and that there is no guarantee of implementation. + - label: 'I have searched the existing issues and improvement suggestions to avoid duplication.' + - label: 'I have provided a clear description of the improvement being suggested.' + - label: 'I have explained the rationale behind this improvement.' + - label: 'I have included any relevant technical details or design suggestions.' + - label: 'I understand that this is a suggestion and that there is no guarantee of implementation.' + validations: + required: true diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index efd681a71..3e829d24b 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -15,11 +15,10 @@ jobs: - uses: actions/stale@v4 with: repo-token: ${{ secrets.GITHUB_TOKEN }} - days-before-pr-stale: 30 - days-before-issue-stale: 30 - stale-issue-message: 'This issue has not seen activity for a while. It will be closed in 30 days unless further activity is detected' + days-before-pr-stale: 90 + days-before-issue-stale: 90 + days-before-issue-close: 180 stale-pr-message: 'This PR has not seen activitiy for a while. It will be closed in 30 days unless further activity is detected.' - close-issue-message: 'This issue has been closed because of inactivity.' close-pr-message: 'This PR has been closed because of inactivity.' exempt-pr-labels: 'WIP,on-hold,needs review' - exempt-issue-labels: 'WIP,on-hold,needs review,roadmap,assigned' + exempt-issue-labels: 'WIP,on-hold,needs review,roadmap,assigned,needs triage' diff --git a/README.md b/README.md index 24d932858..6d2fab334 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,5 @@ +>We are nominated for a Product Hunt Gold Kitty 😺✨ and appreciate any support: https://documen.so/kitty + Documenso Logo

@@ -13,9 +15,9 @@ · Issues · - Roadmap + Upcoming Releases · - Upcoming Launches + Roadmap

@@ -115,10 +117,12 @@ To run Documenso locally, you will need Want to get up and running quickly? Follow these steps: -1. [Clone the repository](https://help.github.com/articles/cloning-a-repository/) it to your local device. +1. [Fork this repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) to your GitHub account. + +After forking the repository, clone it to your local device by using the following command: ```sh -git clone https://github.com/documenso/documenso +git clone https://github.com//documenso ``` 2. Set up your `.env` file using the recommendations in the `.env.example` file. Alternatively, just run `cp .env.example .env` to get started with our handpicked defaults. @@ -152,10 +156,12 @@ npm run d Follow these steps to setup Documenso on your local machine: -1. [Clone the repository](https://help.github.com/articles/cloning-a-repository/) it to your local device. +1. [Fork this repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) to your GitHub account. + +After forking the repository, clone it to your local device by using the following command: ```sh -git clone https://github.com/documenso/documenso +git clone https://github.com//documenso ``` 2. Run `npm i` in the root directory @@ -280,12 +286,16 @@ WantedBy=multi-user.target ### Railway -[![Deploy on Railway](https://railway.app/button.svg)](https://railway.app/template/DjrRRX) +[![Deploy on Railway](https://railway.app/button.svg)](https://railway.app/template/bG6D4p) ### Render [![Deploy to Render](https://render.com/images/deploy-to-render-button.svg)](https://render.com/deploy?repo=https://github.com/documenso/documenso) +### Koyeb + +[![Deploy to Koyeb](https://www.koyeb.com/static/images/deploy/button.svg)](https://app.koyeb.com/deploy?type=git&repository=github.com/documenso/documenso&branch=main&name=documenso-app&builder=dockerfile&dockerfile=/docker/Dockerfile) + ## Troubleshooting ### I'm not receiving any emails when using the developer quickstart. diff --git a/apps/marketing/content/blog/commodifying-signing.mdx b/apps/marketing/content/blog/commodifying-signing.mdx new file mode 100644 index 000000000..0a9cf4050 --- /dev/null +++ b/apps/marketing/content/blog/commodifying-signing.mdx @@ -0,0 +1,87 @@ +--- +title: Commodifying Signing +description: We are creating signing as a public good and are commoditizing it to make it cheaper and better. +authorName: 'Timur Ercan' +authorImage: '/blog/blog-author-timur.jpeg' +authorRole: 'Co-Founder' +date: 2024-01-25 +Tags: + - Vision + - Mission + - Open Source +--- + +
+ + +
+ Lighthouses are often used as an example of a public good; As they benefit all maritime users, but no one can be excluded from using them as a navigational aid. Use by one person neither prevents access by other people, nor does it reduce availability to others. +
+
+ +# Commodifying Signing + +> TLDR; We are creating signing as a public good and are commoditizing it to make it cheaper and better. + +While we are in full-on building mode with Documenso, I think a lot about the big picture of what we are attempting to do. One phrase that keeps popping up is, "We are commodifying signing." Let's dig deeper into what that means. + +Let's start with why we are doing this. Documenso's mission is to solve the domain of signing once and for all for everyone. In so many calls, I hear stories about how organizations build their own solution because the existing ones are too expensive or need to be more flexible. That means not hundreds but probably thousands of companies worldwide have done the same. This is simply wasting humanity's time. Since digital signing systems are understood well enough that seemingly "everyone" can build them, given enough pain, It's time to do it once correctly. + +## Is signing already a commodity? + +> In economics, a **commodity** is an economic good, usually a resource, that has explicitly full or substantial fungibility: that is, the market treats instances of the good as equivalent or nearly so with no regard to who produced them. + +That sounds like the signing market today. There is no shortage of signing providers, and you can get similar signing services from many places. So why is this different from what we want, and why does this not satisfy the market? + +- Signing is expensive and painful when you are locked into your vendor, and they charge by signing volume. +- Signing is also expensive and painful when you have to build it yourself since no vendor fits your requirements or you are not allowed to + +To understand why, we need to look at the landscape as it is today: + +- **Commodity**: Signing SaaS +- **Private Goods**: Signing Code Base, Regulatory Know-How +- **Public Goods**: Web Tech, Digital Signature Algorithms and Standards + +What the current players have done is to commodify the listed public goods into commercial products: + +> […]the action and process of transforming goods, services, ideas, nature, personal information, people, or animals into commodities. +> (Let's ignore the end of that list for now and what it says about humanity, yikes) + +While this paradigm brought digital signing to many businesses worldwide, we aim for a different future. To solve signing once and for all, we need to achieve two core points: + +- Making it cheaper so it's profitable for everyone to use +- Making it more accessible so everyone can use it (e.g. regulated industries) and flexible enough (extendable, open). + +To achieve this, we must transform the landscape to look like this: + +- **Commodities**: Enterprise Components, Support, Hosting, Self-Host Licenses +- **Public Goods**: (no longer private): OS (Open Source) Signing Code Base, OS Regulatory Know-How +- **Public Goods**: OS Web Tech, Digital Signature Algorithms and Standards + +## Raising the Bar + +Before creating a commodity, we are raising the bar of what the underlying public good is. Having an open source singing framework you can extend, self-host, and understand makes the resulting solution much more accessible and extendable for everyone. Now for the final feat of making signing cheaper: + +As we have seen, signing has already been commodified. But since it was done by a closed source and, frankly, a very opaque industry, no downward price spiral has ensued. By building Documenso open source with an open culture, we can pierce the veil and trigger what the space has been missing for a long time: Commoditization. If you had to read that again, so did I: + +> In business literature, **commoditization** is defined as the process by which goods that have economic value and are distinguishable in terms of attributes (uniqueness or brand) become simple commodities in the eyes of the market or consumers. + +By only selling what creates value for the customer (hosting a highly available service, keeping it compliant, supporting with technical issues and challenges, preparing industry-specific components), we are commoditizing signing since everyone can do it now: The resources enabling it are public goods, aka. open source. A leveled playing field, as described above, is the perfect environment for a community-first, technology-first, and value-first company like Documenso to flourish. + +## Changing the Game + +In this new world, a company needing signing (literally every company) can decide if the ROI (Return on Investment) of building signing themselves is greater than simply paying for the value-added activities they will need anyway. Pricing our offering not on volume but fixed is a nice additional wedge into the market we intend to use here. + +The market dynamic now changes to who can offer the greatest value added to the public goods, driving the price down as this can be done much more efficiently than locking customers into closed source SaaS. Documenso, being a lean company, which we intend to stay with for a long time, will help kickstart this effect. Open Source capital efficiency is real. Our planned enterprise components, hosting support, and partner ecosystem will all leverage this effect. + +We will grow our community around the public good, the open-source repo, and create an ecosystem around the commodities built on top of it (components, hosting, compliance, support). We will solve signing once and for all, and the world will be better for it. Onwards. + +As always, feel free to connect on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments. + +Best from Hamburg\ +Timur diff --git a/apps/marketing/content/blog/email-provider-incident-2024-01-10.mdx b/apps/marketing/content/blog/email-provider-incident-2024-01-10.mdx new file mode 100644 index 000000000..0f5279d6e --- /dev/null +++ b/apps/marketing/content/blog/email-provider-incident-2024-01-10.mdx @@ -0,0 +1,28 @@ +--- +title: Jan 10th Email Provider Security Incident +description: On January 10th, 2022, we were notified by our email provider that they had experienced a security incident. +authorName: 'Lucas Smith' +authorImage: '/blog/blog-author-lucas.png' +authorRole: 'Co-Founder' +date: 2024-01-17 +tags: + - Security +--- + +On January 10th, 2024 we were notified by our email provider that a security incident had occurred. This security incident which had started on January 7th led to a bad actor obtaining access to their database which contains ours and other customer’s data. + +We understand that during this security incident the following has been accessed: + +- Email addresses. +- Metadata on emails sent excluding the email body. + +While the incident is unfortunate we are pleased with the remediation and the processes that our email provider has put in place to help avoid this kind of situation in the future. Since the incident, our provider has rectified the issue and has engaged a security company to conduct an exhaustive investigation and to help improve their security posture moving forward. + +We remain steadfast in our commitment to our current email provider, and will not be taking any further action with relation to changing providers. + +We are now working with our legal counsel to ensure that we provide the appropriate notice to all our customers in each jurisdiction. If you have any further questions on this incident please feel free to contact our support team at [support@documenso.com](mailto:support@documenso.com). + +We appreciate your ongoing support in this matter. + +You can read more on the incident on our providers blog post below: +[https://resend.com/blog/incident-report-for-january-10-2024](https://resend.com/blog/incident-report-for-january-10-2024) diff --git a/apps/marketing/content/blog/linear-gh.mdx b/apps/marketing/content/blog/linear-gh.mdx new file mode 100644 index 000000000..1267931d6 --- /dev/null +++ b/apps/marketing/content/blog/linear-gh.mdx @@ -0,0 +1,115 @@ +--- +title: Moving from Linear to GitHub & LIVE Roadmap 2.0 +description: We are leaving linear and are going all in on GitHub. Here is how we do it. +authorName: 'Timur Ercan' +authorImage: '/blog/blog-author-timur.jpeg' +authorRole: 'Co-Founder' +date: 2024-01-10 +Tags: + - GitHub + - Backlog + - Roadmap +--- + +# From Linear to GitHub + +> TLDR; We are leaving Linear and are using only GitHub going forward. We no longer communicate feature timelines, only what we are working on and what's next. + +If you follow us, you know we have been in full-on build mode. We are building, the community is building, it's great. Building is our daily business, so we think a lot about improving our approach to doing it. +Our most recent approach is to reduce the number of tools and platforms we use. Every tool we use + +- Reduces the average time you spend on the tool +- Reduces your focus +- Increases mental load to keep all points of interest in mind + +We thought about where we spend the most time, and hardly surprising: it's GitHub. Not only do we spend a lot of time there, but we also WANT to spend a lot of time there because: + +- It's where the community contributes, and we are all about community +- It's where we show the world what we are working on + +# The old structure + +So far, we have been using Linear for our Backlog/ Task Management and synced issues we want to showcase or work on with the community via synclinear.com. Not only did we have our development issues there, but since +we have our own resident founding designer, we created a proper design backlog to structure our design workflows. + +# The new structure + +We moved everything to GitHub once we realized our focus was already there. This has a few key benefits: + +- Reducing dilution of attention and time: You can hang out on GitHub without risk of missing much +- Putting different aspects of Documenso close to each other: Development, Design, Community +- Keep long-term, niche, and very abstract issues out of the main repo so we don't get desensitized by large issue numbers + +To achieve this, we created a few GitHub repositories to host issues, with the main repository remaining the central point of interest, especially for the community. + +## 1. Main Repository - Day to day Issues and the shorter-term roadmap (LIVE Roadmap 2.0) + +> [github.com/documenso/documenso](https://github.com/documenso/documenso) + +Apart from the source code of the Documenso app and website, the main repo houses issues raised by the community and issues where we invite the community to participate. +With the overhauling of our issue management, we are also updating our progress communication. While the software and product development process is highly complex, +we try to give as much insight into what we do as possible. To that end, we went through 3 phases, three being what we do now. + +1. **One extensive roadmap**: Initially we had one roadmap and were (very) slowly checking off boxes there (via a "Roadmap" milestone). While this is easy, it's also pretty imprecise and not practical as the project grows +2. **Estimated releases per quarter**: To give better guidance, we tried communicating our goals for the quarter; a pretty big window we thought we could roughly "hit". While the idea of not being too detailed was good, it is tough to estimate when some significant things are done if you do a lot of minor/ other things in parallel, + like working with the community and tuning things you go. Hitting time targets is tricky because there may be better things to do than sticking to that time target. This is always much easier to grasp for the people closely involved. The fallacy is to assume the thing you plan for exists in a vacuum. +3. Since we do not want to limit ourselves in choosing the most effective course but still give some insight into what's going on and what's coming up, we updated the live roadmap [https://documen.so/live](https://documen.so/live). It now shows what we are currently working on and what we plan on doing next. We do not provide + a specific timeline anymore since we couldn't even if we wanted to. Of course, we set our short-term goals based on what's best for the community. We give updates on the issues being worked on as well as possible. + +## 2. Public Backlog - The longer-term roadmap + +> [github.com/documenso/backlog](https://github.com/documenso/backlog) + +The public backlog houses everything we want to build eventually. We do not provide a specific timeline of when that might happen. If we decide against something, it will be removed from the public backlog, as we consider this our long-term vision for Documenso. If you are interested in something on the roadmap, comment on the issue or post on Discord. This helps us gauge interest in specific features. +**Issues in the public backlog are not** available to be worked on. For issues to work on, please check the main repository issues. The issues found here are scoped broader since they are not meant for immediate execution but rather give a sense of where Documenso is going and what we consider part of our domain. + +## 3. Internal Backlog + +> github.com/documenso/backlog-internal + +
+ + +
+ Our internal Kanban for development +
+
+ +This serves as the direct replacement for our Linear backlog. Here, we manage issues that are either too small or short-term for inclusion in the long-term roadmap, yet too specialized or fundamental to be integrated into the main repository. Our development Kanban board is implemented using a GitHub project. + +## 4. Internal Design Backlog + +> github.com/documenso/design-internal + +
+ + +
+ Our internal Kanban for design +
+
+ +This is the design equivalent of the internal backlog. The internal design backlog houses our design projects that include the exploration of new features, detailed UI designs, and improving the platform overall. +It's similar to the Kanban board for the development backlog. + +## 5. Public Design Repository + +> [github.com/documenso/backlog-design](https://github.com/documenso/design) + +While the internal design backlog also existed in Linear, the public design repository is new. Since designing in the open is tricky, we opted to publish the detailed design artifacts with the corresponding feature instead. +We already have design.documenso.com housing our general design system. Here, we will publish the specifics of how we applied this to each feature. We will publish the first artifacts here soon, what may be in the cards can be found on the [LIVE Roadmap](https://documen.so/live). + +Feel free to connect with us on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions or comments! We're always here to help and would love to hear from you :) + +Best from Hamburg\ +Timur diff --git a/apps/marketing/content/blog/manifest.mdx b/apps/marketing/content/blog/manifest.mdx index 4abd7c068..7f2b7e7cd 100644 --- a/apps/marketing/content/blog/manifest.mdx +++ b/apps/marketing/content/blog/manifest.mdx @@ -7,6 +7,8 @@ authorRole: 'Co-Founder' date: 2023-07-13 tags: - Manifesto + - Open Source + - Vision ---
diff --git a/apps/marketing/content/blog/pre-seed.mdx b/apps/marketing/content/blog/pre-seed.mdx index fae0a6c4a..215700355 100644 --- a/apps/marketing/content/blog/pre-seed.mdx +++ b/apps/marketing/content/blog/pre-seed.mdx @@ -1,6 +1,6 @@ --- title: Announcing Pre-Seed and Open Metrics -description: We are exicited to report the closing of our Pre-Seed round. You can find the juicy details on our new /open page. Yes, it was signed using Documenso. +description: We are excited to report the closing of our Pre-Seed round. You can find the juicy details on our new /open page. Yes, it was signed using Documenso. authorName: 'Timur Ercan' authorImage: '/blog/blog-author-timur.jpeg' authorRole: 'Co-Founder' diff --git a/apps/marketing/content/blog/shop.mdx b/apps/marketing/content/blog/shop.mdx index fafd98a40..cb5b65554 100644 --- a/apps/marketing/content/blog/shop.mdx +++ b/apps/marketing/content/blog/shop.mdx @@ -30,7 +30,7 @@ We kicked off [Malfunction Mania](https://documenso.com/blog/malfunction-mania) ## Documenso Merch Shop -The shirt will be available in our [merch shop](https://documen.so/shop) via a unique discount code. While the shirt will be gone after Malfunction Mania, the shop is here to stay and provide a well-deserved reward for great community members and contributors. All items can be earned by contrinuting to Documenso. +The shirt will be available in our [merch shop](https://documen.so/shop) via a unique discount code. While the shirt will be gone after Malfunction Mania, the shop is here to stay and provide a well-deserved reward for great community members and contributors. All items can be earned by contributing to Documenso.
+ + +
+ Not the burger from the story. But it could be as well, the place is pretty generic. +
+
+ +> TLDR; I started Documenso because I wanted to build a modern tech company in a growing space with a mission bigger than money, I overpaid for a SSL cert 13 years ago, like encryption, and wanted to help make the world/ Internet more open. + +It's hard to pinpoint when I decided to start Documenso. I first uttered the word "Documenso" while sitting in a restaurant with [Felix](https://twitter.com/flxmgdnz), eating a burger and discussing what's next in late 2022. Shortly after, I sat down with a can of caffeine and started building [Documenso 0.9](https://github.com/documenso/documenso/releases/tag/0.9-developer-preview). Starting Documenso is the most deliberate business decision I ever made. It was deliberate from the personal side and deliberate from the business side. + +Looking at the personal side, I've had some time off and was actively looking for my next move. Looking back, I stumbled into my first company. Less so with the second one, but I joined my co-founders and did not develop the core concept myself. While coming up with Documenso, I was deliberately looking for a few things, based on my previous experiences: + +- An entrepreneurial space that was a big enough opportunity +- A huge macro trend, lifting everything in it's space +- A mode of working that fits my flow (which, luckily for me, is pretty close to the modern startup/ tech scene) +- A more significant impact to be made than just earning lots of money (though there is nothing wrong with that) + +Quick shoutout to everyone feeling even a pinch of imposter syndrome while calling themselves a founder. It was after ten years, slightly after starting Documenso, that I started doing it in my head without cringing. So cut yourself some slack. Considering how long I've been doing this, I would have earned the internal title sooner, and so do you. After grappling with my identity for a second, as is customary for founders, my decision to start this journey came quickly. + +Aside from the personal dimension, I had a clear mindset of what I wanted. The criteria I describe below clicked into place one after another, in no particular order. Having experienced no market demand and a very gritty, grindy market, I was looking for something more fundamental. Something basic, infrastructure-like, with a huge demand. A growing market deeply rooted in the ever-increasing digitalization of the world. + +And to be honest, I just always liked digital signature tools. It's a product that is easy enough to comprehend and build but complex and impactful enough to satisfy a hard need. It's a product you can build very product-driven since the market and domain are well understood. So when asked about what's next for me, I literally said, "Digital, um, let's say… signatures". As it turns out, my first gut feeling was spot on, but how spot on I only realized when I started researching the space. An open source document signing company happens to be the perfect intersection of all the criteria and personal preferences I described above; it's pretty amazing, actually: + +- The global signing market is enormous and rapidly growing +- To put it bluntly, the signing space is vast and dominated by one outdated player. Outdated in terms of tech, pricing, and ecosystem +- The signing space is also ridiculously opaque for a space based on open web tech, open encryption tech, and open signing standards. Even by closed-source standards +- We are currently seeing a renaissance for commercial open source startups, combining venture founder financials with open source mechanics +- Rebuilding a fundamental infrastructure as open source with a meaningful scale has a profoundly transformative effect on any space +- Working in open source requires being open, cooperative, and inclusive. It also requires quite a bit of context jumping, "going with the flow," and empathy +- Apart from fixing the signing space, making Documenso successful would be another domino tile toward open source eating the world, which is great for everyone + +Building a company is so complex it can't be planned out. Basing it on great fundamentals and the expected dynamics is the best founders can do, in my humble opinion. After these fundamental decisions, you are (almost) just along for the ride and need to focus on solving the "conventional" problems of starting a company the best you can. With digital signatures hitting so many points of my personal and professional checklist, this already was a great fit. What got me excited at first, though, apart from the perspective of drinking caffeine and coding, was this: + +Roughly 13 years ago, I was launching my first product. We obviously wanted SSL encryption on the product site, so I had to buy an SSL certificate. ~$200ish, two years validity, from VeriSign, I think. Apart from it being ridiculously complicated to get, it bothered me that we had basically paid $200 for what is essentially a long number someone generated. SSL wasn't even that widespread back then because it was mainly considered important for e-commerce, no wonder considering it cost so much. "Why would I encrypt a blog?". Fast forward to today, and everyone can get a free SSL cert courtesy of [Let's Encrypt](https://letsencrypt.org/) and browsers are basically blocking unencrypted sites. Mostly, it is even built into hosting platforms, so you barely even notice as a developer. + +I had forgotten all about that story until I realized this is where signing is today. A global need fulfilled only by a closed ecosystem, not really state-of-the-art companies, leading to, let's call it, steep prices. I had considered Let's Encrypt a pillar of the open internet for so long that I forgot that they weren't always there. One day, someone said, let's make the internet better. Signing is another domain that should have had an open ecosystem for a long time. Another parallel to that story is the fact that the cryptographic certificates you need for document signing are also stuck in the "pre-Let's Encrypt world." Free document signing certificates via "Let's Sign" are now another to-do on the [long-term roadmap](https://documen.so/roadmap) list for the open signing ecosystem. Effecting this change in any way is a huge driver for me. + +Apart from my personal gripes with the corporate certificate industry, I have always found encryption fascinating. It's such a fundamental force in society when you think about it: Secure Communication, Secure Commerce, and even [internet native, open source money (Bitcoin)](https://github.com/bitcoin/bitcoin) were created using a bit of smart math. All these examples are expressions of very fundamental human behaviors that should be enabled and protected by open infrastructures. + +I never told rthis to anyone before, but since starting Documenso, I realized that I underestimated the impact and importance of open source for quite some time. When I was in University, I distantly remember my mindset of "yeah, open source is nice, but the great, commercially successful products used in the real world are built by closed companies (aka Microsoft)" _shudder_ It was never really a conscious thought, but enough that I started learning MS Silverlight before plain Javascript. It was slowly, over time, that I realized that open web standards are superior to closed ones, and even later, I understood the same holds true for all software. Open source fixes something in the economy I find hard to articulate. I did my best in [Commodifying Signing](https://documenso.com/blog/commodifying-signing). + +To wrap this up, Documenso happens to be the perfect storm of market opportunity, my interests, and my passions. Creating a company in which people want to work for the long term while tackling these issues is a critical side quest of Documenso. This is not only about building the next generation of signing tech; it's also about doing our part to normalize open, healthy, efficient working cultures and tackling relevant problems. + +As always, feel free to connect on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord) if you have any questions, comments, thoughts or feelings. + +\ +Best from Hamburg\ +Timur diff --git a/apps/marketing/package.json b/apps/marketing/package.json index 83d13d07c..1cfb7337f 100644 --- a/apps/marketing/package.json +++ b/apps/marketing/package.json @@ -36,7 +36,7 @@ "react-hook-form": "^7.43.9", "react-icons": "^4.11.0", "recharts": "^2.7.2", - "sharp": "0.32.5", + "sharp": "0.33.1", "typescript": "5.2.2", "zod": "^3.22.4" }, diff --git a/apps/marketing/public/blog/burgers.jpeg b/apps/marketing/public/blog/burgers.jpeg new file mode 100644 index 000000000..4fd897e75 Binary files /dev/null and b/apps/marketing/public/blog/burgers.jpeg differ diff --git a/apps/marketing/public/blog/gh1.png b/apps/marketing/public/blog/gh1.png new file mode 100644 index 000000000..f28ce70c2 Binary files /dev/null and b/apps/marketing/public/blog/gh1.png differ diff --git a/apps/marketing/public/blog/gh2.png b/apps/marketing/public/blog/gh2.png new file mode 100644 index 000000000..7ea7d4fa9 Binary files /dev/null and b/apps/marketing/public/blog/gh2.png differ diff --git a/apps/marketing/public/blog/lighthouse.jpeg b/apps/marketing/public/blog/lighthouse.jpeg new file mode 100644 index 000000000..d71e1eb51 Binary files /dev/null and b/apps/marketing/public/blog/lighthouse.jpeg differ diff --git a/apps/marketing/src/app/(marketing)/[content]/page.tsx b/apps/marketing/src/app/(marketing)/[content]/page.tsx index 5c846e9f2..62c83f400 100644 --- a/apps/marketing/src/app/(marketing)/[content]/page.tsx +++ b/apps/marketing/src/app/(marketing)/[content]/page.tsx @@ -15,7 +15,7 @@ export const generateMetadata = ({ params }: { params: { content: string } }) => notFound(); } - return { title: `Documenso - ${document.title}` }; + return { title: document.title }; }; const mdxComponents: MDXComponents = { diff --git a/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx b/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx index f1952cc72..866539a92 100644 --- a/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx +++ b/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx @@ -18,7 +18,9 @@ export const generateMetadata = ({ params }: { params: { post: string } }) => { } return { - title: `Documenso - ${blogPost.title}`, + title: { + absolute: `${blogPost.title} - Documenso Blog`, + }, description: blogPost.description, }; }; diff --git a/apps/marketing/src/app/(marketing)/blog/page.tsx b/apps/marketing/src/app/(marketing)/blog/page.tsx index 747a56ddf..2eac963d1 100644 --- a/apps/marketing/src/app/(marketing)/blog/page.tsx +++ b/apps/marketing/src/app/(marketing)/blog/page.tsx @@ -1,5 +1,10 @@ +import type { Metadata } from 'next'; + import { allBlogPosts } from 'contentlayer/generated'; +export const metadata: Metadata = { + title: 'Blog', +}; export default function BlogPage() { const blogPosts = allBlogPosts.sort((a, b) => { const dateA = new Date(a.date); diff --git a/apps/marketing/src/app/(marketing)/layout.tsx b/apps/marketing/src/app/(marketing)/layout.tsx index 248414b33..dd1a46418 100644 --- a/apps/marketing/src/app/(marketing)/layout.tsx +++ b/apps/marketing/src/app/(marketing)/layout.tsx @@ -41,7 +41,7 @@ export default function MarketingLayout({ children }: MarketingLayoutProps) {
-
{children}
+
{children}