I think a more charitable interpretation of Elastic's motives in the re-licensing would be to view them the same as your motives for your side project -- allow free use to anyone except those wanting to offer it as a hosted service. You say that you've licensed your side project with MIT and Apache2 but with an exclusion. In other words, it's neither MIT nor Apache2 and it's unclear how your exclusion would hold up legally (hopefully well!). At Elastic's scale, uncertainty over a license is too risky, so I'm sure they paid their lawyers $$$ to ensure that the SSPL would hold up in the scenarios that were important to them.
There's a fair amount of hyperbole in that statement. Most of the above products (Redis, Elasticsearch, MongoDB, etc.) don't have "thousands of individual contributors" and are developed primarily by employees of the backing companies.
Second, external contributors can use it in their work in any way that they want so long as it's not in offering Elasticsearch-as-a-service. They can even use for offering Elasticsearch-as-a-service so long as it's based on the current Apache2-licensed code rather than the SSPL-licensed code that will be in effect as of the next Elasticsearch release.
There are certainly valid criticisms of this decision, but a blanket statement that "thousands of individual contributors" are the losers here is an exaggeration.
Interesting. I got the impression from the recent announcement that Grafana Labs had something of a revenue sharing model with the new AWS managed offering of Grafana. Given that, I wouldn't think the SSPL restrictions would be as important.
You're right -- it's only the free "X-pack Basic" code that will now be available under SSPL. But that does mean that all Elasticsearch distributions will now include the former "X-pack Basic" features.
I don't think it's really that different. Elastic did that same thing about three years ago when they made all of their enterprise-only features source-available (https://www.elastic.co/blog/doubling-down-on-open). Timescale also made their enterprise features free of charge, but that's a business decision rather than a question of licensing. It's because their revenue model is based completely on their managed cloud offering while Elastic still gets non-trivial revenue from selling their enterprise features to customers who want them.
They'll have to base their service off the last Apache-2 version of Elasticsearch. Unrelated to this license change, but they'll probably have to rename it, too, after the trademark infringement suit finishes.
Saying that TeamCity is their worst product sounds like a back-handed compliment to me. It's certainly not a perfect product, but I've been in multiple jobs where they migrated the CI system (including one that did ~25k builds/day) to TeamCity and it was a significant improvement in scalability and manageability over Jenkins, Travis, and some other Windows-only CI system.
Ironically, I called to cancel mine a couple days ago (without knowing about the retention offer) and the CSR asked why. I said that the reduced benefits and increased annual fee made it no longer worth it for me and I was then offered the $250 statement credit. I accepted since that drops the annual fee to a reasonable level. I don't know if I'll stay next year without an additional offer, though. At the previous annual fee of $450, before COVID when I traveled a fair bit for work, and with easily-transferable points for personal air travel, the benefits easily paid for the annual fee. Now work travel is all canceled, the annual fee is up to $550, and their points can't be redeemed for travel on several of the airlines that I flew most frequently. Ah well, first-world problems.
A similar kind of automated mechanism is required in distributed systems that allow for rolling upgrades. New functionality in upgraded nodes can't break not-yet-upgraded nodes and legacy behavior in not-yet-upgraded nodes has to be tolerated in upgraded nodes but only until the entire system is upgraded and then it is prohibited. Doing this wrong results in some really hard to fix production states.
Fast food in the US is significantly more expensive than preparing your own food from basic ingredients. There may be some lower-income people who eat lots of fast food, but it's certainly not because it's the economical choice.
There's no way that Elastic would accept the Open Distro features as a contribution to Elasticsearch because they include inferior versions of features already available in the commercially-licensed version of Elasticsearch and, in the case of the Search Guard code in Open Distro, code that Elastic alleges was lifted from existing commercially-licensed Elasticsearch features. AWS knows all this but offers it anyway as a PR stunt so they can say that they at least attempted to make contributions to Elasticsearch.
Also agreed. To whatever extent it's helpful, this is my take on it:
Elasticsearch:
* Data streams -- an abstraction that eases management of a set of indices containing time series data.
* Wildcard data type -- makes searching for partial strings much more efficient
* EQL -- a new query language that's popular in the SIEM (security info and event mgmt) world
* Miscellaneous new aggregations
* Tableau connector for Elasticsearch
Other parts of the stack:
* free version of Workplace Search (index all your stuff from multiple sources such as Gmail, Google Drive, MS Sharepoint, Salesforce, etc.)
* free version of endpoint security from Elastic's acquisition of Endgame
* Ingest Manager/Elastic Agent -- centrally manage and configure Beats-based endpoint agents that push metrics, monitoring, etc. to Elasticsearch
* new rendering engine in Kibana
Yes, shocking how many managers make this mistake. I've seen this happen most recently right after the covid-19 market drop and the company announced hiring and salary freezes. A sudden team meeting with no agenda and titled something along the lines of "Team changes." How much worse could that be?
That said, it is a "management smell" when someone who is fired is surprised about it. There should definitely be preceding feedback to the employee that things are not working well and an opportunity to improve them first.
The headline doesn't distinguish between remote work at companies that are remote-first vs. companies where remote is simply an afterthought or tolerated option. Promotions, raises, influence, etc., are no issue for remote workers in the former kind of company but certainly can be in the latter. Even though the article mentions Gitlab, a remote-first company, it doesn't tease out the distinction. Given market pressures, I expect the best remote workers to gravitate to companies that are remote-first, not just remote-available.
The Abbott test may not be used everywhere. I've called them to confirm their labs local to me use the Abbott test and that's probably what you should do if you're looking to get this test. While it does not guarantee that they use the Abbott test in every region, you can see that they reference Abbott in the footnotes for question #3 in their FAQ on COVID-19 testing here: https://education.questdiagnostics.com/faq/FAQ219
Though I would love for this to be causal, this analysis needs to control for the experience level of the developer. IME, developers who work remotely tend to be more on the experienced end of the spectrum.
I was hopeful that Xpra would provide reconnectable remote sessions for me on my Linux workstations but I found it pretty difficult to configure with poor documentation. If there are any better installation guides out there, I'd appreciate a pointer to them.
I have a 40" 4k monitor that can fit 2 or 3 windows horizontally when helpful, but I agree that its killer feature is how useful the extra height is for coding. I also have two smaller monitors on either side for things like Slack or Github that are often referenced but aren't usually part of "flow" work.
Doesn't the Thinkpad P7x line of laptops still tick all those boxes? The only one it might not have is dual RJ45 ports, but I'd think a USB RJ45 port would suffice in the cases where a second LAN port was required.
I have a Ring doorbell which works great, but I put in a fake street address when registering it for this reason. So far as I've seen, it loses none of its utility from that. The only user-visible feature based on the address is the "neighborhood crime alerts" feature which I don't want since I live in a dense enough city that petty crime "near" me isn't really a concern.
FWIW, that sounds relatively similar to the licenses that Redis Labs, Mongo, and Elastic recently applied to their software. I have no problem with that, but judging from the discussions here on those licenses, lots of other people did.
This strikes me as a bit of a straw man -- "AWS has operational skill. Open source companies with managed service offerings of their software probably do not." The operational skills that AWS has are primarily at the infrastructure layer. If my experience with their managed software services and the tons of complaints in their support forums are any indication, their operational excellence drops off dramatically at the software layer. I don't fault AWS for trying to move up the value chain, but bashing on open source companies as "not a viable business model" distracts from the real question of who can delivery a better managed software offering on top of AWS's (or GCP's or Azure's) managed hardware platform.
I used to have a Sony Xperia that had the fingerprint sensor integrated into the power button on the side of the phone. IMO, that was perfect because it could be unlocked either when held in one hand or when sitting on a flat surface. I think a single smartphone manufacturer managed to patent that idea in the US so it's not more widely used.