Lessons in Vendor Lock-in: Google and Huawei

Your Weekly Newsletter [view in browser »]( Want to stay more up to date on all things open source? Follow us on [Twitter](. [Fists]( Lessons in Vendor Lock-in: Google and Huawei Kyle Rankin - July 5, 2019 What happens when you're locked in to a vendor that's too big to fail, but is on the opposite end of a trade war? The story of Google no longer giving Huawei access to Android updates is still developing, so by the time you read this, the situation may have changed. At the moment, Google has granted Huawei a 90-day window whereby it will have access to Android OS updates, the Google Play store and other Google-owned Android assets. After that point, due to trade negotiations between the US and China, Huawei no longer will have that access. Whether or not this new policy between Google and Huawei is still in place when this article is published, this article isn't about trade policy or politics. Instead, I'm going to examine this as a new lesson in vendor lock-in that I don't think many have considered before: what happens when the vendor you rely on is forced by its government to stop you from being a customer? Too Big to Fail Vendor lock-in isn't new, but until the last decade or so, it generally was thought of by engineers as a bad thing. Companies would take advantage the fact that you used one of their products that was legitimately good to use the rest of their products that may or may not be as good as those from their competitors. People felt the pain of being stuck with inferior products and rebelled. These days, a lot of engineers have entered the industry in a world where the new giants of lock-in are still growing and have only flexed their lock-in powers a bit. Many engineers shrug off worries about choosing a solution that requires you to use only products from one vendor, in particular if that vendor is a large enough company. There is an assumption that those companies are too big ever to fail, so why would it matter that you rely on them (as many companies in the cloud do) for every aspect of their technology stack? Many people who justify lock-in with companies who are too big to fail point to all of the even more important companies who use that vendor who would have even bigger problems should that vendor have a major bug, outage or go out of business. It would take so much effort to use cross-platform technologies, the thinking goes, when the risk of going all-in with a single vendor seems so small. [read article]( [Terminal]( Finishing Up the Bash Mail Merge Script Dave Taylor - July 4, 2019 Finally, I'm going to finish the mail merge script, just in time for Replicant Day. Remember the [mail merge script]( I started writing a while back? Yeah, that was quite some time ago. [Read Article]( [Neal Stephenson]( In the End Is the Command Line Doc Searls - July 3, 2019 Times have changed every character but one in Neal Stephenson's classic. That one is Linux. [Read Article]( [Keyboard]( Contributor Agreements Considered Harmful Eric S. Raymond - July 8, 2019 Why attempts to protect your project with legal voodoo are likely to backfire on you. [read article]( in case you missed [July Cover] The Command-Line Issue Bryan Lunduke - July 1, 2019 Summer. 1980-something. An elementary-school-attending, Knight Rider-T-Shirt-wearing version of myself slowly rolls out of bed and shuffles to the living room. [Read Article »]( [Screenshot] GIS on Linux with SAGA Joey Bernard - July 12, 2019 In this article, I want to look at a GIS option available for Linux—specifically, a program called [SAGA]( (System for Automated Geoscientific Analyses). [Read article »]( upcoming events [Open Source Summit North America]( August 23, 2019 - August 24, 2019 San Diego, California USA [HPC on Wall Street]( September 11, 2019 - September 12, 2019 New York, NY USA [All Things Open]( October 13, 2019 - October 15, 2019 Raleigh, North Carolina USA [Rancher]( [Storix Software]( [Twistlock]( [PIA]( Subscribe to Linux Journal for only $2.88 an issue! [Subscribe Now »]( [Renew Now »]( You are receiving this email because you signed up to receive newsletters from Linux Journal. You can [update your preferences]( or [unsubscribe]( from this list. Copyright © 2019 Linux Journal LLC, All rights reserved. Mailing address: 9597 Jones Rd, #331 Houston, TX 77065