I'm not a customer of yours, but your blog posts inspired me a lot. Your journey through quitting caffeine is a great and heartening read.
I've got two things to say;
1) Will you consider source-availabling the web portal (app.keygen.sh) too? Some enterprises could use it for easy management/support for customer's licenses. Although now that I think about it, it could also discourage custom, more suitable implementations for each use-case... I'm torn on this one. I would like to see it available on GitHub just out of curiosity too. It's very beautiful.
2) For a team + customers' chat, I cannot recommend Zulip enough. It's a joy to use and has the most innovative chat system I've ever seen. https://zulip.com
> Will you consider source-availabling the web portal (app.keygen.sh) too?
I will. But I actually want to completely rebuild the portal app so that it’s easier to maintain. I (and everybody else) also want more customer-facing features, e.g. license management and offline activation, as well as white-label capabilities.
Right now, the dashboard is a pretty dated Ember app that I threw together in a couple weeks about 6 years ago. It’s hard to maintain, but does its job (mostly). I’ve been planning to completely start from scratch with React, but open sourcing the API and rebranding has been my main priority.
The new portal app will be open source too, likely under a more permissible MIT license.
I've been following Keygen for quite a few years (but alas, no projects suitable to try it), partly because of the excellent docs about licensing schemes, and partly because licensing systems (and the breaking thereof) have been a recurring interest to me ever since punching in a building's worth of XP keys and wondering, none of these boxes are connected to anything... how do they know what I typed in is valid?
For that reason, Keygen shocked me when it first came out as a public(!) licensing platform... how could they get away with documenting their secret sauce?
Cheers to you ezekg, and may transparent licensing schemes prevail.
It looks like they very carefully did not claim it to be open source :)
As somebody who typically dislikes the Elastic license, this is really a great use of it:
- it used to be completely closed source, so it's not taking any previous contributions and putting a more restrictive license on it;
- there is clearly quite a bit of thought in choosing this license over something like AGPL (complete with somebody taking to themselves on GitHub), and the license was chosen based on the goals;
- the software in question is really not that useful for non-commercial uses anyway, so people who want to freeload doesn't have that much to stand on
Even though I'm not a user (and don't see myself using it in the future), I'd nevertheless be happy for them and hope they do well :)
They explicitly used the phrase "keygen is now open source". Tenth sentence overall, 6th paragraph from the top:
"After 7 years of being closed source, I'm incredibly excited to announce that Keygen is now open source! Let's unpack what that means for us and for you."
You’re right. For the announcement, I used the term “open source” because people generally know what it means (especially in the context of previously being “closed source”). Saying I made something source-available(d?) ends up being confusing to a lot of people who don’t know what that means.
Outside of the announcement and 2/3 of the blog post, I use the phrase “open, source-available.”
What you are doing is trying to get the benefits of claiming that you are open source, without truly making it open source.
What is open source is well known in the industry. If you search on google what open source mean - you will find that you don't fit the criteria.
It would be much more ethical to truthfully say what you are doing. And don't get me wrong, what you are doing is still great.
I disagree. If I was trying to take advantage of it, I'd use the term "open source" everywhere like some other projects do. But I tried to find a middle ground so the zealots would be happy(ish). But in the end I'll never make everybody happy, regardless of how much I stress about words [0] [1].
I started my indie electron app a year after Keygen started. I looked at Keygen when I launched a version of my app off the app stores. I needed a way to license and have complete control.
At the time, Keygen didn’t do everything I needed (but it probably does now), so I’m not a user. However, I’ve always looked at Keygen and its solo dev with great respect. I just knew that we were going to be successful in our niches and although we haven’t helped each other with direct product offerings, just know that Keygen made me feel like I could do anything.
Because we are talking license servers … My license server is node+mongo and vends licenses as JWT. My desktop app verifies the JWT and uses the payload to unlock features. They work offline. Pretty slick! I’m proud of what we’ve built. Truly standing on the shoulders of giants.
Best of luck on your open sourcing of Keygen! Let me know if you’re ever in the Midwest USA and we can grab a meal or beverage together.
Not a ton, I suspect. On macOS there'd be app signing/notarizing issues and you'd probably have to disable gate keeper or knock another hole in the walled garden.
The real "trick" is keeping the app inexpensive and the purchase low friction. If I raised prices there'd be more pressure to pirate. People who need my app are solving a "terrible problem" (printing labels). They aren't the kind of customer that would seek out a pirated copy or try to pirate it.
For example, for a period of time the app's licensing could be bypassed by starting another 14 day free trial using a different email address. After watching these "clones" keep re-registering every two weeks (for maybe 20 weeks!), I finally updated the licensing to be slightly more restrictive: you can register again but the 2nd free trial on any particular computer is limited to 4 hours, the 3rd registration doesn't show a free trial.
Guess what happened? ~50 new customers over two weeks, all from a particular geography. It was wild. But I've had no complaints.
Long story short: People will pay to solve the soul-crushing task of label printing. I joke that I write the colonoscopy of the software world. It can be a dirty job.
What laptop GPU? I tried to tone it down a bit for iGPUs but I may need to tweak it more. Sorry about that. Runs smooth on our 2019 MBPs, iPad minis, and iPhones, but I know that’s not a big test pool. It’s a webgl fragment shader, so it’ll be GPU-heavy, not CPU-heavy.
(I wish there was an easy way to disable the shader based on GPU specs…)
Celeron N4500 and whatever's built in on that, on Linux, which I admit is not very fast, but as far as I can remember this is the first time I encountered an issue with it, and it's fast enough to play RimWorld and such so it's not completely trash either.
I'm not a customer of yours, but your blog posts inspired me a lot. Your journey through quitting caffeine is a great and heartening read.
I've got two things to say;
1) Will you consider source-availabling the web portal (app.keygen.sh) too? Some enterprises could use it for easy management/support for customer's licenses. Although now that I think about it, it could also discourage custom, more suitable implementations for each use-case... I'm torn on this one. I would like to see it available on GitHub just out of curiosity too. It's very beautiful.
2) For a team + customers' chat, I cannot recommend Zulip enough. It's a joy to use and has the most innovative chat system I've ever seen. https://zulip.com
I hope your business keeps prospering!