Your framing seems somehow backwards. Based on the other article[0] Nate and David bought out the business from Blue Systems. Jonathan (previously employed by Blue) proposes a co-op model, the new owners say “no thanks, we’re good”. Jonathan is surprised at this, storms out, detonating all the bridges on the way.
My framing seems backwards because I’m commenting on what Nate wrote, not on what Jonathan wrote. As you and I have both said, with the way the world works now Nate is within his rights not to want to found a cooperative, and Jonathan is within his rights to be surprised that none of his colleagues care about this like he does.
My point is simply this: Nate shouldn’t pretend that the model he’s proposing is or ever will become the kind of thing Jonathan is advocating for, because it’s not and will not, but I think Nate is pretending that.
From what Jonathan wrote, I also don’t think he intended to storm out. I think he intended to advocate for something, likely with enough frustration and emotion that others who disagreed with him noticed the intensity of his feelings, and they decided to exclude him from further discussions to avoid drama rather than ever engaging with him to give their firm final decision in a calm but explicit way. They weren’t willing to give him a clear final no and instead ostracized him as part of their implicitly stated no.
To be clear, I agree with your implication that Jonathan likely didn’t handle this in the way that would be best for his professional career going forward, insofar as he may not have been calm and diplomatic in his private advocacy and then went quite public with the level of venting we just read. But Nate’s response didn’t make him look good either; it felt as disingenuous as Jonathan’s earnest blog post may have been interpersonally unwise.
Personally I prefer earnest but interpersonally unwise over disingenuous, since it’s easier to fix with constructive criticism and emotional support. But I know a lot of investors and employers don’t feel that way.
I think Jonathan was disappointed because he honestly thought he was among like-minded friends, people he'd known and worked with for so long; he clearly didn't expect to be rebuffed so hard.
I've been in similar situations, and it's hard to stay professional in those cases. The feeling of personal betrayal is significant. Add to this that most old-school Linux hackers like him are often motivated by striving for social justice, and somewhat expect everyone who works with them to fundamentally wish the same things. Discovering that long-term collaborators actually wish to be regular techbros, must sting.
Yeah, a lot of different types of people get involved in this ecosystem, not only the stereotypical primarily altruistically motivated old-school hacker. This is especially true for the for-profit sector rather than among the purely volunteer part of the community.
That said, only some of them would be tech bro wannabes. Others might not want to try to rock the boat in this awful economy, in the sense of not wanting the career consequences of having been part of a failed attempt to form a cooperative when the company ends up capitalist in the end, or simply might be skeptical that a cooperative would succeed well enough to meet their genuine financial needs.
I am a Debian developer myself, though quite inactive for the last 6 or so years due to life circumstances. Plenty of people even in that world end up working for the man, in such forms as Google or Dropbox or the like, even if they’d rather not. Life is expensive and the world is capitalist with bills to pay.
I used to work for Blue Systems for about 7 years, including a turn as its CTO, until 2019. I was not party to the Techpaladin transition in any way and have no special knowledge on that, but I did work with many of the people who remain there now and recruited quite a few of them from the commmunity.
I just want to say that none of that team are "techbros" or in it for the money. I was a volunteer, entirely unpaid KDE contributor for another 7 years before BS came along, and many of the other contractors and employees were similarly long-time contributors already. BS as well operated for a long time without a specific profit motive.
I was the person who very initially set up the Valve project that TP now continues to work on, and as a team we simply took to the idea of working with Valve because it meant having a solid customer who was interested in doing foundational work upstream to improve KDE software, which is what we all wanted to do the most. Valve's user audience - gamers who take their computers seriously and love using them - overlaps KDE's in spirit in many ways, Valve's engineers absolutely know their stuff and ask for the right things, and it all made a lot of mission sense immediately.
This is all very much still done by oldschool hackers who will keep the lights on probably till the end of their productive careers.
Good to know! To be clear, when I said “only some would be tech bro wannabes”, I was commenting on the general pattern and not the specific incident or people. I didn’t mean that assertion to imply anything about any of the particular individuals or companies involved in this story.
In other words, I meant “only some of the people in the industry who react to situations like this the way Jonathan’s peers seem to have according to his blog post would be tech bro wannabes”. That may very well not be true for anyone at Blue Systems / Techpaladin, and indeed my point was that it would be true for “only some” such people in the industry in general and definitely not true for all of them.
The only reason I even addressed the possibility of the “techbro” mindset at all is because it was mentioned by the person I was replying to; it wouldn’t have otherwise been something I would have thought to mention in this context.
I do have quite a high general opinion of the ethics of KDE hackers as well as the technical side of Valve. (I have no strong opinion either positive or negative on the business side of Valve, though I do appreciate their kindness in sharing Steam keys for their products with Debian developers back when they were basing SteamOS on Debian as well as allowing Debian to distribute Steam in its non-free section.)
It’s commendable to want to start a “cooperative socialist paradise”, you can pitch it and see if there’s interest with others. But it’s totally OK as well for others to not want to join that, and go the more conventional way.
It sounds like Nate is set on starting a conventional company, and that should be fine. The previous company apparently never made financial sense so it also doesn’t work to just continue that model directly and so things and people get cut. It can be both hard to communicate and to hear, doubly so when you’re emotionally invested. That’s why IMO it’s important to separate your self worth from your job at some level, for your own mental wellbeing.
We bought our .com after we became "successful" and had significant revenue, however it just redirects to our non-dot-com, because it's too much of a hassle and SEO risk to change at this point.
If I as a SaaS provider get my SSO SAML integration via a provider like Okta or Auth0, the auth provider pricing itself is also on a "call us" tier, with a per-federation pricing in the low four figures for each individual company connecting to me via SAML.
It's pretty insane, so I'll state it again: To have a company connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege. Not counting the base enterprise tier pricing for the auth solution itself. So then I have to roll my own solution if I want to provide it for free, and I get the joy of supporting the long tail of broken SAML implementations on both the service and identity provider sides. For free. In a perfect world SSO wouldn't be a shitshow and everyone could have it for free, unfortunately that is not this world.
The SAML world is definitely a fun mess. We’re[1] building out SAML support and are beta testing it with a few customers and it is funny how different even the large IDPs are. Add in things like needing to test the integration, making sure attribute and role mappings are correct, and it’s unfortunate but understandable that companies not specializing in auth wouldn’t want to deal with it except for customers that pay a lot.
Plugging in my startup BoxyHQ here. This is the reason why we open sourced our SAML integration - https://github.com/boxyhq/jackson, it should be commodity.
Fwiw, Amazon offers an sso platform with saml for free. That's not the answer for everyone though, and may not be for you even. Just putting it out there for those looking for a cheap saml identity provider.
Except that with Deno, everything IO related is turned off by default and has to be granted access before it becomes a process. It's the first bullet point on the landing page.
That still doesn't prevent imported modules from yoinking anything you did grant access to, though. For instance, if my service connects to a DB then `uuid` can slurp the contents.
It'd be nice to have some capability model where modules can only access things through handles passed to them, but probably infeasible for a project like this.
From the article: "Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission."
Does Deno have some built in way to vendor / download the imports pre-execution? I don't want my production service to fail to launch because some random repo is offline.
You can also use the built in bundle command to bundle all of your dependencies and your code into a single, easily deployable file. https://deno.land/manual/tools/bundler.
Deno caches local copies and offer control on when to reload them. in term of vendoring you can simply download everything yourself and use local paths for imports.
How would this work with transitive dependencies? Sure I can control which parts I import myself, but how do I keep a vendored file from pulling in another URL a level deeper?
Unlike node, recommended deno practice is to check-in your dependencies to the VCS.
> Production software should always bundle its dependencies. In Deno this is done by checking the $DENO_DIR into your source control system, and specifying that path as the $DENO_DIR environmental variable at runtime.
Ah from that perspective I can see how this might appear to be better. Personally, I like the 'magic' of NPM (which to be honest I don't really think is all that magical, it's quite transparent what's happening behind the scenes). This 'magic' means I no longer have to write 200 line makefiles, so it definitely makes my life easier.
Some of that convenience will still be included, a couple of things that deno will do differently from node will be that there is no standard index.* file to load and import path include the extension.
If business travel is reduced, you can expect the cost of regular coach class tickets to increase massively as the former pays for the flight and the latter is just there to wring a bit more profit out of the trip.
Business travel right now is non-existent and many companies are finding that things still work just fine without it and will not return to previous spend levels.
Tickets to leisure destinations are not out of line from flights on business routes, so I don’t think it’s right to say airplanes can’t fly profitably without business travelers footing the bill.
Zoom works great on Linux, it's a proper native app and the quality is excellent. Screensharing is notoriously tricky on Wayland and has been a shifting target that is just now starting to settle, I'm sure it'll eventually work.
[0] https://pointieststick.com/2025/03/10/personal-and-professio...