I know this doesn't add much value to the discussion, but I was really proud of my UIN when I was a teenager. And this may be my last chance to flaunt it, so here it is:
1779900
So back in the day, these were known as Universal Internet Numbers, or UINs. You have to admire the sheer audacity of using that name for the user identifiers of a service you're building. I believe they were renamed to "ICQ#" later.
I have been self-employed since 2008, when I quit my job in software engineering to go all-in on my software business (that dated from 2003). That failed spectacularly, because I only focused on technology and not on the value I was creating, and with few customers, I had to do on-site contracting for more than a year before going on full-time parental leave.
I then rebooted my software project, launched a landing site and started talking to prospects (hundreds of them), before I set out to pivot my existing product to something that might gain traction. (I wound up throwing away 95 percent of the code.) I spent 2014 through 2019 with the product in beta, barely making a living off of a few enterprise support contracts and doing freelance photography (and depleting my savings), but spending at least 80 percent of my time on building the product and getting it to a finished state.
(Some people seem to be able to build a product in a weekend that gets eager customers. I'm not one of those people, choosing to build something that was, in retrospect, much too big of a project for one person. I probably also spent too much time polishing the product before commercializing it, likely due to a fear of failure.)
In 2019, the product was finally commercialized as a SaaS service. I remember thinking that I either wanted it to be a spectacular success, or a spectacular failure (so that I could focus on other things, after close to 20 years).
It was neither, but has been growing steadily ever since. I would have made much more money working for someone else, but the freedom is unparalleled. I get to set my own hours and focus on things I consider important. I enjoy doing everything from support calls and UX work to building a compiler and a type system (that I have mentioned before on HN).
I also have no one I need to answer to, other than our customers. That has been important over the past couple of years, when a series of health emergencies in my family has diverted my attention elsewhere. I have been very fortunate to be able to do so, focusing on what's important, without having to ask permission to cut down on work temporarily.
Overall, I wouldn't trade this for anything. This year, my product will gain a sister product in a more lucrative field (I'm hoping), and I have plans to commercialize my compiler, both as a service and as a traditionally-licensed library. So I'm excited to stay solo and keep working on building the business.
Thanks, it certainly has been. After only a couple of years in the software industry proper, though, I felt I had seen all I needed to see. Crunch time. Arbitrary, ill-informed management decisions. Management who didn't believe in the product the team was passionate about. Products canceled through no fault of anyone working on it. Office politics and bickering.
With my own business, I gain agency. If the product fails, it's because I failed to market it properly, or the product vision was bad and did not resonate with enough customers, or because I failed to execute on that vision. When all the decisions are out of your hands, and you can't even see what prompted them, they can feel capricious and arbitrary.
With my own business, I am in control. I don't have one boss, I have hundreds of them. And as long as I continue to provide them with value, I get to continue doing what I'm doing. I like those terms.
Yes, to all of that. But: the amount of control is directly proportional to how fat your wallet is, as it gets leaner you lose some of that agency so make sure you never even go close to depleting your reserves. That's a lesson I learned the hard way at some point and it causes me to be pretty cautious from a financial perspective. So far so good ;)
Could someone provide insights into the implications of a hypothetical Schrems III for EU-based SaaS companies that host their servers in the US, particularly those containing Personally Identifiable Information (PII) like email addresses? Essentially, would Schrems III mean that we'd need to immediately move our servers to EU soil, or risk fines?
Whether your servers are in the US or not, if you do business in the EU, EU rules apply. It might be that you will legally not be able to offer your services in the EU, if you have servers in the US, because those can the accessed by US authorities at any time, without you even learning about it.
It is probably safer to have servers in the EU, if you want to do business in the EU. Servers in the EU not provided by any US hoster, since that hoster is vulnerable to being ordered in the US to transfer data from EU to the US.
Everyone -- thanks for your constructive comments. I think that we'll start off by releasing the libraries under permissive licenses, and see how that goes. Releasing the code of the user-facing products publicly would probably provide little value for others (as the code would not be open source), and there are indeed risks.
No, it just feels like the right thing to do, and I'm hoping that others could benefit from the work. While I would like to release some libraries under permissive licenses, I really have no plans to shepherd collaborative open source projects (which I think might turn into a huge time sink). Others would obviously be welcome to fork and maintain these projects, but I would prefer for them to simply be read-only versions of what we're using in production.
A would-be competitor, in a country not respecting intellectual property laws, might get a few customers by launching our product and charging only a fraction of what we charge. However, what will this competitor do when their customers request new features or report bugs? Obviously, we'd be a lot more nimble in responding to such requests, so maybe this shouldn't be such a big concern after all.
Also, if this does becomes a problem, we can just stop releasing new versions publicly, at which point the competitor's offering would stagnate, while our offering would continue to improve.
No. Worst case scenario is that the competitor has more resources than you and can be even more nimble at adding new features and fixing bugs. Because you made all the source code available, you lost all the 'head start' you had against such a competitor.
The service is named Calcapp, an app builder for spreadsheet-savvy users (https://www.calcapp.net). The codebase weights in at half a million lines of code and documentation, with lots of generic utility libraries I have written over the past ~20 years, in Java and JavaScript.
I don't think that releasing the user-facing app creator and runtime libraries under a permissive license would be smart. However, I would still like that code to be out there, and for the utility libraries to be available for anyone to use under a permissive license.
The one downside I can see myself is that by making the source available, we might reveal security vulnerabilities. Sure, security through obscurity is not a good idea in and of itself, but revealing that we haven't updated a key, vulnerable library might still be problematic.
I am on my phone so couldn't really test it out, but it sounds sufficiently niche that it could both benefit or be harmed by releasing the code.
Usually, the hardest bit is getting the infrastructure set up, so if you do have dozens of intertwined components, just pushing the code might not really help anyone.
Still, I think it depends on the business you have and market you are covering, more than the app itself. Eg. if your market is huge, somebody will want to jump in. If it's tiny, nobody else is probably going to bother even if you made it trivial to deploy and run. And there is a huge continuum of options in between :)
One thing I've seen was default to AGPL after, say, 3 years after release. Depending on the development pace, you might make that 1 or 5 years. In general, this means you could AGPL the version from 5 years ago today.
> You're probably referring to the wonderful nXML mode
But wasn't there an issue where early nxml mode for Emacs would not support the Relax NG using the XML syntax? I vaguely remember the compact Relax NG syntax being supported but not the XML one. And for whatever reason that XML syntax for Relax NG was supported under XEmacs.
It was really a long time ago so my memory is very fussy but something like that. Since then I switched back to Emacs and I do use nxml-mode (I don't use Relax NG anymore though).
I was told that Firefox is no longer supported by a support technician over the phone. A different support technician wrote this to me in an email:
"Regarding the printing option on Firefox, I'm afraid this is no longer within Stripe's support scope."
(I complained that it is not possible to print certain pages of the Dashboard through Firefox, while Chrome works acceptably well.)