This Week in Programming: “Knock Yourself Out, Go to Amazon”
“If you want a cheap place to run something, you might choose to go to Amazon, and it will not be monetizable for us in the first place. Knock yourself out, go to Amazon.”
Those are the words of YugaByte co-founder and Chief Technology Officer Karthik Ranganathan speaking to Business Insider this week about his company’s decision to change YugaByte DB licensing to 100% open source. In the blog post detailing the decision and the reasoning behind it, Ranganathan announces that YugaByte DB is now 100% open source under the Apache 2.0 license, including all of the “previously closed-source, commercial, enterprise features such as Distributed Backups, Data Encryption and Read Replicas.”
'competition from AWS is simply the price to pay for developing OSS' https://t.co/dy6A1xLQDM
— Jordan Novet (@jordannovet) July 17, 2019
Previously, YugaByte had gone by an open core model, keeping the enterprise features under a proprietary license. While the company will open those features up under Apache 2.0, the potentially more interesting part of the announcement concerns what they will be doing with their YugaByte Platform, which they are releasing now under a source available, free-trial-only license from the Polyform Project. This license does not meet the criteria of open source, but rather make the source available under a trial period, during which a company may “use to evaluate whether the software suits a particular application for less than 32 consecutive calendar days.”
the notable thing is them starting to use standardize source available license via polyform for the intended commercial bits, while the rest is fully open and no fauxopen shenanigans https://t.co/zcTjXyFrJo
— Chris Aniszczyk (@cra) July 16, 2019
The Polyform project, writes Business Insider, is “a brand-new type of software licensing agreement, authored by […] a team of open source licensing lawyers, including Heather Meeker, an attorney and prominent figure in helping MongoDB and the others in their defensive action against the major cloud providers.”
“A healthy commercial business is a must-have for continued investment in open source, especially in the context of single-vendor [Open Source Software] projects,” writes Ranganathan. “The open core monetization model is where much of the recent licensing debate has focused on. For database and data infrastructure companies, open core has traditionally meant reserving a certain class of ‘enterprise’ features for a separate commercial edition.”
Smart move….adoption now will Drive monetization later….key partnerships is another lever #startups #ensw
— AP Guha (@APGuha) July 16, 2019
Ranganathan expands the company’s thoughts on the topic of monetization under the subtitle “DB Monetization is Dead, Long Live DBaaS Monetization.”
“We at YugaByte believe that if AWS wants to build a managed service based on an OSS project, there is almost nothing that can be done to stop it — competition from AWS is simply the price to pay for developing OSS. Restrictive licensing including AGPL can slow down AWS but cannot stop it so the real impact of such licensing is lower user adoption. And even if AWS builds a service, that becomes a great validation of the staying power of the OSS project and gives users more confidence that their investment will remain protected through multi-party competition. But this means that a commercial OSS company now has to compete with AWS on the merits of an exceptional DBaaS experience and not on the merits of the core OSS DB.”
So there you have it, another chapter in the saga of open source database monetization and the various methods of handling competition. (Also? Just click the link in the tweet below. It’s worth it.)
— Wayne Witzel III (@wwitzel3) July 18, 2019
This Week in Programming
- Should Rust Replace C and C++ for Safety? Earlier this year, we looked at a talk from Microsoft security engineer Matt Miller, who noted that most Windows vulnerabilities boiled down to memory safety issues caused by C and C++. Well, Microsoft has decided it should, perhaps, take a proactive approach to more secure code and it’s starting a blog series on the topic, starting out with the idea of looking at Rust as an alternative. “What more could the developer want from security engineering?” they ask, answering that “for starters, they might want to have to spend less effort on learning tools and processes to build features without security flaws.” Thus, they make their case for memory-safe languages, such as Rush and C#. While, they note, that “C++ does have its virtues that make it attractive and in some cases essential: it is blisteringly fast, it has a small memory and disk footprint, it’s mature, it’s execution predictable” and so on, they posit that Rust combines some of these requirements, while also offering memory safety. “Rather than providing guidance and tools for addressing flaws, we should strive to prevent the developer from introducing the flaws in the first place,” they write. Sounds like a plan, eh?
Now that Alan Turing is on the 50 pound note, they should rename ATMs to “Turing Machines”
— mdowd (@mdowd) July 18, 2019
- Python 3.8 Is Headed Our Way: The next version of Python is on the way and SDTimes takes a look this week at what to expect in Python 3.8, noting that the second beta was released earlier this month, making Python 3.8 feature complete, with two more planned beta release previews before the official version is released in October. Some of the noteworthy features in the next version of Python include assignment expressions, positional-only arguments, runtime audit hooks, Python initialization configuration, vectorcall, and pickle protocol 5 with out-of-band data. Also of note, writes SDTimes, is the “new governance model that was implemented last year,” which introduced “a five-person steering council is […] used to establish standard practices and introducing new features.” According to a post by the Python team, “the council has broad authority, which they seek to exercise as rarely as possible; instead, they use this power to establish standard processes, like those proposed in the other 801x-series PEPs. This follows the general philosophy that it’s better to split up large changes into a series of small changes that can be reviewed independently: instead of trying to do everything in one PEP, we focus on providing a minimal-but-solid foundation for further governance decisions.” For an even more in-depth look at Python 3.8, including some of the inside baseball, check out the Linux Weekly News post.
- The Why Behind The Rigid C++Release Schedule: We love taking a look at the behind the scenes work that goes into making programming languages what they are, and ISO C++ standards committee chair Herb Sutter offers a look at why the C++ standard ships every three years, writing simply that “WG21 has a strict schedule (see P1000) by which we ship the standard every three years. We don’t delay it.” In an attempt to head off the regular questions of why the timeline is so strict, which he says arrive “around this time of each cycle,” Sutter drafted a FAQ that goes through “the reasons why we do it this way, and some of the history behind the decision to adopt this schedule.” According to the post, there are just two project management options available: “Pick the features, or pick the release time, and whichever you pick means relinquishing control over determining the other. It is not possible to control both at once.” Well, C++ chose option two, and if you have questions from there, we recommend that you read the FAQ.
https://twitter.com/russellbrandom/status/1151491939688222720
- Facebook Open Source Hermes: If mobile app performance is of interest to you, then so too will Facebook’s newly open sourced Hermes JavaScript engine optimized for mobile apps. In trying to figure out mobile app performance, Facebook writes that it “noticed that the JavaScript engine itself was a significant factor in startup performance and download size” and so they set out to “optimize JavaScript performance in the more constrained environments of a mobile phone.” The result is a new JavaScript engine called Hermes, that is “designed to improve app performance, focusing on our React Native apps, even on mass-market devices with limited memory, slow storage, and reduced computing power.” According to the blog, Hermes offers faster time to interact, smaller download size, and better memory utilization, and does so by employing bytecode precompilation, an ahead-of-time compiler instead of a just-in-time compiler, and an enhanced garbage collector strategy. To get started, check out the full instructions for the migration to use Hermes on React Native.
#Microservices simplifies code by trading code complexity for operational complexity. #Serverless reduces code by giving away control to gain velocity.
Every #Architecture is a trade-off commitment. ⚖️
— Bilgin Ibryam (@bibryam) July 12, 2019
Feature image: Britain’s new £50 note featuring Alan Turing.
