compsciphd
Joined 14 years ago
Joined 14 years ago
Large employers are usually self-insured. The insurance company just manages the plan, but the employer actually pays the medical claims out of pocket.
Offering indefinite COBRA means absorbing massive medical risk for people who no longer work for you and aren't providing value. Healthy ex-employees leave COBRA quickly for cheaper coverage, while those with heavy medical expenses stay as long as possible—so the company gets stuck paying for high-cost claims while only collecting basic premiums.
While some companies let retirees buy into a group plan, that's an earned perk to reward long tenure. Indefinite COBRA would give that same lifetime benefit to anyone, even if they worked there for only six months.
Basically both described in https://www.usenix.org/legacy/event/lisa11/tech/full_papers/... (in detail) and https://www.usenix.org/conference/usenix-atc-10/apiary-easy-... (in a "sexy" use case to try and motivate it) a few years prior. (and I get annoyed when people say "so you're saying you invented containers?" because they equate docker with containers. And I'm like no, containers existed for a long time going back to logical partition on mainframes in the late 70s/early 80s. All I claimed was a novel way of building and distributing file systems for them that made them much more useful and valuable and in apiary a novel desktop setup that made use of it to improve desktop security)
Even the original docker implementation of using a union fs (docker using aufs) was the exact same as described.
Even if docker came up with it independently (though conferences like LISA and Usenix ATC are where the papers were presented and were where companies like dotcloud/docker would advertise their wares (and in fact docker inc was an exhibitor there, so it wasn't hidden), the differences between the uniqueness of docker and what is described in the paper are minor (in my perhaps somewhat biased opinion of course), and i was clearly first.
ephemeral, instant boot strap, append only (I'm pretty sure I was the first person to use ephemeral computing this way, at the time I couldn't find anything that touched it. People used containers, ala ZFS/Zones, but they were generally meant for long term computing and not for bringing up an environment for a very small period of time and then tearing it down.)
This paper with bellovin applied it to system administration - https://www.usenix.org/legacy/event/lisa09/tech/full_papers/...
though we also approached recording and forking your computation at will - https://dl.acm.org/doi/10.1145/1323293.1294289 (I'm proud of coining the name), though it strongly relates to Microsoft's recall so it would probably be viewed less positively today (in fact, this might be closer in implementation to what they are doing than the above).
with that said, it was a bit more tongue in cheek than anything.
as an aside, I sort of wonder in the age of AI and the ability to reproduce anything easily, we might have to expand patents (related to comment below that got downvoted), but dont have strong thoughts on this yet.
https://www.usenix.org/conference/usenix-atc-10/apiary-easy-...
https://www.usenix.org/legacy/event/lisa11/tech/full_papers/...
To put a device into (or out of) law enforcement mode, can only be done over bluetooth (i.e. in proximity to device)./
decisions that lose community can be reversed, but the consequence of those decisions (losing community) might not be reversible at any cost. Which it seems to be in this case.
As an example, at the company I switched to, they no longer use redis internally (not selling redis as a service, just using it as the internal caching layer of the product and never directly exposed to users, so would be a valid free use case under the switched to license) and instead use valkey.
While these use cases might never have made Redis Inc any significant amounts of money, they were free advertising that they gave up and even with the 2nd license change, is not something they've gained back as external contributors are more interested in valkey than redis.
And that goes to the email I wrote to leadership before the decision was publicized. 1) what are we trying to accomplish 2) what would be the negative consequence of the decision 3) is there another way to accomplish #1 while minimizing #2.
It was always clear to everyone that #2 would be a fork. Everyone already knew that Amazon was managing their own internal Redis repo where they did their own internal development and then would drop changes that they would benefit from not having to carry (vs Redis Inc doing a lot of their core redis work in public vs dropping completed things)
If #1 was to prevent Amazon et al from using redis trademarks, I don't think the license had to change. If #1 was to enable more non BSD code to be part of redis, I don't think the license of the core had to change. (how this would have impacted redis naming in linux distribution that only want to ship OSS code is a semi open Q but I think solvable).
Personally, I think keeping the core as BSD but including the the non BSD source available portions could have been an effective "trojan horse" for getting the community at large to be more invested in those pieces.
Also personally, I think what caused Redis Inc leadership to go down the path they did was Amazon cloning a non bsd source available redis module that Redis Inc published (RedisJson, to the point that they cloned the entire api including "easter eggs" that weren't really meant to be used, i.e. an API alias named after a (former) executive JSON DEL vs JSON FORGET named after former sales VP Jason Forget). That was the point of Amazon no longer playing nice in a competitive friendly way on the BSD code level, but to try to undermine how Redis Inc tried to distinguish themselves from just the BSD code. That's the right, but it perhaps caused Redis Inc to make bad decisions. (and as an aside, in today's day and age of AI, I wonder what protection these source available licenses have from AI oriented cloning).
1) bundle the "source available" modules as part of redis source distribution 2) enable people who only want bsd code to be able to build a "redis_core" 3) commit to the community that the core will remain BSD licensed and that they are committed to making it the best key/value store. 4) increase the amount of source available code that until then had been kept closed (including what we called big redis/RedisOnFlash/MultiTier) 5) Require anyone using the redis trademarks in a commercial setting to ship the entire Redis (which includes the source available portions, so Amazon et al would no longer be able to use the Redis trademarks without a license deal.
Another alternative was to simply go to AGPL (which they went to anyways awhile later).
I failed to convince the leadership about this. I honestly think they squandered huge value in community engagement, but perhaps that's what they wanted. I left a bit after these changes were made as it became clear that the new US led leadership of the company wasn't particularity interested in what was the soul of redis. (previously was heavily Israeli led and a critical mass there was invested in redis as an open source product).
Funny story, the then new/current CEO used to be the head of WebEx at Cisco. We had a Q&A when he was hired and I asked, what did he learn from his time at WebEx about how to maintain market position (as they lost everything to zoom et al). His response at the time wasn't that convincing, but I was willing to give him the benefit of the doubt. I feel its fair to ask if the same thing occurred again.
Or to put it slightly differently. do you believe with this knowledge now out that they didn't do their job that it will drive more voters to the? While I can't predict how much it will hurt them, I can't imagine a world where it actually helps them. They failed again.