Open sourcing Keygen

[ezekg]

About time. I’ve wanted to do this since day 1.

Pros

• Larger adoption in enterprise/on-prem. They regularly ask about self-hosting.
• Better customer success regarding compliance (GDPR, security, etc.)
• Learn how larger corps deploy software on-prem and in the cloud (e.g. Docker, k8s).
• Word of mouth growth.
• Market leader. Snuff out the infinite stream of copycats.
• Community.
• DevRel boost from going OSS.
• Marketing about going OSS.
• Lessens pushback concerning my “bus-factor.”
• Risk-adverse businesses can still use Keygen by self-hosting.
• Build trust.
• Less sales, more technical support? (The Dream™)

Cons

• Security issues, known and unknown, become real issues. Get an audit beforehand? (See prereqs.)
• Customers may cancel and self-host. This is my livelihood. (See sustainability.)
• People think my code is 💩.

Sustainability

• No, or “best effort”, support. No guarantees. Guaranteed support contracts can be purchased, aiming at larger corps at $999+/mo. May also help funnel smaller accounts into SaaS, since support pricing would be out of their price-range.
• Quarterly release schedule. (I.e. updated self-hosting docs, new official GH release, Docker images, etc.)
• Faster release schedule and security notifications for self-hosted customers.
• Remove free tier from Cloud version? Instruct free users to self-host.
• Charge setup fee for helping self-hosted customers onboard.
• Create paid add-on for SSO (use a Rails Engine). SSO will be a part of Keygen EE.
• Enable GH sponsorships.

Community

• Slack group? Discord server? Or Matrix chat?

License

• GNU Affero General Public License V3 (AGPLv3). (See also Cal.com, Plausible.)
• Business Source License (BSL). (Also see Sentry.)
• Elastic License v2 (ELv2). (See also Elastic, Airbyte, Bearer.)
  • This did not go well: https://news.ycombinator.com/item?id=28683124
  • This did: https://news.ycombinator.com/item?id=34693233
  • This maybe did: https://news.ycombinator.com/item?id=35055843
  • Not good: https://news.ycombinator.com/item?id=21191676
  • Shit show: n8n is not open source and your project is gaslighting its users n8n-io/n8n#40
  • Bad: Use of "Open Source" wording without using an Open Source license openreplay/openreplay#638

Good reads

• https://www.linkedin.com/pulse/how-we-picked-our-open-source-license-cloudkeeper-framework-kamp/
• https://writing.kemitchell.com/2021/01/20/Righteous-Expedient-Wrong.html
• https://writing.kemitchell.com/2019/05/05/Rely-on-OSI.html
• https://airbyte.com/blog/a-new-license-to-future-proof-the-commoditization-of-data-integration
• https://plausible.io/blog/open-source-licenses
• https://cal.com/blog/longevity

Prereqs

• Add permission system #470.
• Encrypt license keys #675.
• Add last checkout timestamp to license and machines #664.
• Extract typed_parameters and envented to gems? (Rewrite typed_parameters.)
• Add a standard Rails Dockerfile.
• Add a SECURITY.md.
• Add an ADOPTERS.md?
• Add a CHANGELOG.md (start with a line e.g. "Keygen goes OSS.")
• Add a .github/FUNDING.yml file for support contracts?
• Update README.md.
• Add a contributor’s license agreement? (See Airbyte and CLA Assistant.)
• Add a deploy-to-Heroku button to README.
• Add a deploy-to-Render button to README.
• Add a deploy-to-Fly button to README.
• Clean up code?
• Security audit?
• Move whitelisted/blacklisted IPs to env vars. Or in addition to Redis?
• Add env vars for app config, e.g.:
  • KEYGEN_LICENSE_FILE=/etc/keygen/ee.lic
  • KEYGEN_LICENSE_KEY=XXXX-YYYY-ZZZZ-V3
  • KEYGEN_HOSTS=api.keygen.sh,stdout.keygen.sh
  • KEYGEN_TENANT_MODE=single|multi (or KEYGEN_MODE=multi[player]|single[player])
    • Multiplayer mode should only be sold to select EE customers. Designed for Keygen Cloud.
  • KEYGEN_REQUEST_LOG_RETENTION=30d
  • KEYGEN_EVENT_LOG_RETENTION=90d
• First release, codenamed: "All Your Licensing Are Belong To Us^W You."
• Write a blog post with the same title as above. (See these examples).
  • Alternate title: "Keygen, a software licensing and distribution API, goes open source"
  • Simple CTA on HN to kick off discussion without answering any questions off the bat:

    Author here!

    Happy to take any feedback or answer questions about this post.

• Add CI. (Note: ensure both CE and EE are tested!)
  • Singleplayer CE
  • Singleplayer EE
  • Multiplayer EE
• Add badges for uptime, CI, etc.:
  • Uptime:
  • CI:
• Close out old issues in all repos.
• Run gitleaks.
• Make Cronitor, Rails Autoscale, and other third-parties, optional.
• Add version support policy (e.g. EOL after 1 year).
• No tracking or telemetry.

Docs

• Cover self-hosted install configuration.
• Cover TRUSTED_PROXIES, HTTP_PROXY, HTTPS_PROXY, NO_PROXY env vars. (See this post from GitLab.)
• Refs: Sentry, Plausible.

Support

• Set up a 1x1 with a Keygen Engineer. Charge fee?

[ezekg]

Related to #640.

[ezekg]

I like Plausible’s self-hosting docs.

[ezekg]

From Airbyte's ELv2 FAQs:

We chose ELv2 because it is very permissive with what you can do with the software.

You can basically build ANY product on top of Airbyte as long as you don’t:

• Host Airbyte yourself and sell it as an ELT/ETL tool, or a replacement for the Airbyte solution.
• Sell a product that directly exposes Airbyte’s UI or API.

Here is a non-exhaustive list of what you can do (without providing your customers direct access to Airbyte functionality):

• I am creating an analytics platform and I want to use Airbyte to bring data in on behalf of my customers.
• I am building my internal data stack and I want my team to be able to interact with Airbyte to configure the pipelines through the UI or the API.
• ...

I'd clarify with "sell a product that directly exposes Keygen’s API for use outside of your product."

[ezekg]

Closing. Heart pounding. Let's see how this goes.