bit_flipper

A lot of what you're saying depends greatly on the exact game you're talking about and what winning and losing means, for instance if the game has discrete places instead of a bimodal winner/loser.

For a few of the games I worked on, random matchmaking like you describe is a non-starter. If you're a 90th percentile player in one of our games, you effectively never lose to a 70th percentile player or below. Your rating will be so high that we can't give you any rating system points for the win. So the person who won got no reward other than the feeling of winning, and the person who lost played a match they had no hope of winning. It ends up feeling pointless to play as a top player because only 1 or 2 matches in 10 on average have any meaning for you. Needless to say, it also feels worse as a low rated player because you simply lose more often.

Thanks for the link, I hadn't read this one yet. Very interesting. I feel like as an industry we're still in the stone ages on how we do skill matching systems. A lot of the current and even future system they describe is really not great, and these flaws are definitely not unique to them (the systems I worked on are even more flawed)! Trying to matchmake dozens of players at a time is such a cool, challenging problem.

I've written game matchmaking before for games and found it far more challenging to do the portions related to matchmaking groups by skill. If you're hyper latency sensitive then perhaps this blog post is really useful? But for the games I worked on we would trade 10ms worse average ping for 10% better skill pairings without question. If you have any advice on improving skill matchmaking I would be quite interested.

Definitely an interesting question. Some things that may explain why --

Mongo was always AGPL and relicensed to SSPL. This had the following consequences:

* Very few companies and zero large cloud companies ever attempted to run the MongoDB codebase in production as a managed service, other than MongoDB the company.

* Mostly because of the above, MongoDB did not receive many code contributions that did not originate from within the company. There were some, but not nearly to the extent of the others you listed

* The difference between AGPL and SSPL is not nearly as large as the difference between BSD and SSPL or Apache and SSPL.

I've run Postgres at large scale (dozens of machines) at multiple companies. I've also run MongoDB at large scale at multiple companies. I like both generally. I don't really care about data modelling differences - you can build the same applications with approximately the same schema with both if you know what you're doing.

I don't understand how folks seemingly ignore Postgres' non-existent out of the box HA and horizontal scaling support. For small scale projects that don't care about these things, fair enough! But in my experience every Postgres installation is a snowflake with cobbled together extensions, other third party software, and home-rolled scripts to make up for this gap. These third party pieces of software are often buggy, half-maintained, and under-documented. This is exacerbated by Postgres' major version file format changes making upgrades extremely painful.

As far as I can tell, there is no interest in making these features work well in Postgres core because all of the contributors' companies make their money selling solutions for HA/sharding. This is an area where MySQL is so significantly better than Postgres (because so many large Internet companies use MySQL) that it surprises me people aren't more unhappy with the state of things. I don't really want to run another Postgres cluster myself again. For a single node thing where I don't care about HA/scaling I do quite like it, though.

You can also build whatever you want with SSPL, as long as absolutely everything you use to run a service that supports it is also licensed as SSPL. It's not that different from the AGPL in spirit.

By which metrics are you evaluating those companies' license changes? Both are significantly more profitable than before they changed licenses, MongoDB especially. I'm not sure there's a causal relationship, but it doesn't seem to have significantly harmed them.

I'm not sure what experience you have, but I've run both their Enterprise licensed database on prem as well as migrated to Atlas and there have never been any licensing issues preventing vertical scaling of databases. One of our clusters on Atlas right now has machines larger than 256GB of RAM -- you're more limited by what your cloud vendor has available than Atlas.

This article seems to have inspired others to look at MongoDB again, so I'll give my thoughts after using it recently.

MongoDB Atlas is a surprisingly good managed database product. I'm not a huge fan of someone else running my databases, but I think it might be the best one you can run across any cloud. If you like MongoDB (and, ignore the memes, there is a lot to like nowadays), and are OK paying a bit more to have someone run your database, I'd strongly consider Atlas.

SSPL has no provision even close to the reach of the "anti-competition" clause Hashicorp is using. While SSPL is not considered open source, it isn't that far off from the AGPL. The difference between SSPL and AGPL is that SSPL (1) is in effect regardless of modification of the service and (2) extends copy left virality to all programs which support running the service, including those that interact with the software over a network.

MongoDB, Elastic, etc. cannot stop you from running a competitor based on the terms of their licenses, they just ask that you publish the source code for whatever service you're running in its entirety (I acknowledge there are disagreements about how far "entirety" extends). The clause in Hashicorp's license actually revokes the right to use their software at all if you're a direct competitor.

OK, no one is going to build an open source competitor to Elastic or MongoDB because then you have no moat and your business will probably fail, I get it, but it's still possible to do without repercussion. It's not like the AGPL is that far off in terms of limitation, either, which is why you don't see many copyleft services run by large corporations unless they've been dual-licensed.

Where is the root of trust for package signatures? Who is verifying signatures: the package index or end-users? How do you distribute public keys? PGP is mostly maligned because of its support for old cryptography standards, some needless cruft, and especially the poor usability of its defacto standardized implementation in GPG, but cosign by itself doesn't actually make any of the trust questions I mentioned go away. There are major tradeoffs to be made about who-trusts-who and what that actually means in terms of security beyond just theatre. I'm not convinced that there exists a good trust mechanism that a package index can enforce that actually moves the needle on supply chain security.