Unfortunately I’d never advocate for something like this at my work. Self-hosting doesn’t make sense in terms of total cost of ownership. I’d rather engineers spent time solving problems in our core business than making sure our wiki is online.
That's a very negative take, and seemingly unfounded.
As with a lot of modern open source, the monetisation comes from providing a hosted/ supported cloud version so your engineers can spend their time solving your core business problems rather than making sure the wiki is online.
That said, it's a Beta, and they've put 12 months into it already to get it where it is.
It's great to have open source competition in this area, so the current lack of a cloud option should put it in the "awesome, I'll check it out, then wait for a cloud option" category.
Being able to self host means you control your infra, so that's a very good property of the tools you use and should probably be a criterion for choosing what you use, even if you don't use the capability yourself. The ability to self-host increases the chances there's something to migrate your data in and out.
The ability to self host also doesn't prevent someone, including the original developers, to also proving hosted services.
And since the presented tool is open source, it's also possible for another company to provide hosting.
All those things are true, but there’s risk associated with going with such a new project with no current monetisation path (especially for something that my colleagues might be putting information into that we might need to access/modify for many years or even indefinitely).
> All those things are true, but there’s risk associated with going with such a new project with no current monetisation path (especially for something that my colleagues might be putting information into that we might need to access/modify for many years or even indefinitely).
Right, though that's orthogonal to the self-hosting aspect.
> Open source isn’t a business model.
Indeed but you can build a solid business model around open source. What do you mean?
So you've never been screwed over by an online-only product becoming horribly shitty, or incredibly expensive? To me, the ability to counteract any insane company policies is a big reason that the ability to self host is incredibly important.
Even if it's just a stop gap solution while we find a better solution to migrate to.
You would be surprised. Many companies have strict requirements for self-hosting. I worked for a couple of these companies, and managed service was a no-go from the start. They (usually) pay far more for that option than what they would usually pay for the managed service.
Other engineers can do hosting just fine. Even a middle schooler copy pasting commands. Sounds like a problem somewhere between the keyboard and the chair.
I think a lot of new entrants to previously-well-explored spaces tend to label themselves as "modern" in order to signify that there is something new about their approach.
For instance, I have a migrations library that I descibre as "modern" because it is designed for a continuous deployment environment where you're automatically running migrations on container startup — there are tons of existing popular migrations libraries, but none of them work this way because they were written in the era that you'd manually run sql commands in prod. I say "modern" so that if anyone finds my library, they realize that it was created recently based on more recent dev/ops trends.
Maybe I should drop the "modern"? I do see a lot of people describe their code as "minimal" or "clean", which is pretty meaningless to me, so I get that "modern" could come across that way as well.
Interesting. My take is more negative than that: modern indicates they are unaware of prior art and the key challenges in the particular space, and consequently the software is buggy and/or fundamentally broken its approach.
I think you should drop “modern” for something like “designed for CI”, “CI-first” or “CI-native”. It’s more informative.
Another issue with using such relative qualifiers IMO is that they become meaningless over time, as the namespace becomes polluted as every few years something addressing some problem with a potentially different approach is given a similar qualifier.
I've noticed it's something a lot of Rust programs describe themselves as. Implying that software written in other programming languages is somehow vintage or obsolete, I guess.
Same, except I take issue with the word "tool." Like a program? A library? A screwdriver? Very ambiguous. Very common these days as well. I don't get it.
Not quite. Could be Call Level Interface, Command Line Interface, Common Language Infrastructure, or Clintonville Municipal Airport which has the airport code of "CLI".
Quite the contrary, I think that env variables have been in this state for this long because they just works and I'm all in with the say "don't reinvent the wheel". I just used modern because it's a tool made in 2023-2024 with Rust, but yeah others may be right that it's just meaningless. I'll probably remove it.
They just wouldn't put you forward most of the time. Having gaps larger than 6 months here (especially if it's in the last decade) is a big red flag. I don't know why, but this has been my experience and others I've spoken to.
Did you re-apply to the same places with and without those factors? Because if you didn’t, it’s hard to be sure what you’re implying is true.
Alternative explanation: you applied for competitive roles and didn’t hear back because there were better candidates, then you applied for less competitive roles and got interviews.
I'd be very surprised if the LLM output is anything _like_ the ORM's, tbh, based on (at this point about a decade old; maybe things have improved) experience. ORMs cannot be trusted.
Indeed, and I find it a problem on land too. I use Miro at work and it is _awful_ on an unreliable internet connection, like on trains in the UK.
I really value local-first software for this reason. I’d like to see more of it.