TechCrunch is a leading technology media property, dedicated to obsessively profiling startups, reviewing new Internet products, and breaking tech news. The blog is dedicated to providing information on MongoDB. Read to know more.
MongoDB announced today that it is acquiring Realm, an open-source database geared for mobile applications, for $39 million. The startup had raised just over $40 million before being acquired today. Not exactly a staggering return on investment.
It’s the kind of acquisition that makes a lot of sense from a tech perspective. Both companies are built on the premise that data is the center of application development, although they both come at it from a bit of a different angle. With Realm, Mongo gets a strong mobile solution, adding to MongoDB Mobile, and it also gets the technology, user base and engineering talent that Realm brings to the table.
Eliot Horowitz, MongoDB co-founder and CTO, sees a company that will blend well with his. “Realm and MongoDB are a natural fit because we share a vision that when developers can interact naturally with data, they are happier and more productive, and because our products are complementary,” he wrote in a company blog post announcing the deal.
Realm has more than 100,000 developers using its product, with 350 companies using its data synchronization tools to move data between mobile devices and the cloud, using the Realm Platform, according to the company.
As you would expect in a deal like this, Realm CEO David Ratner sees this as a way to expose Realm to more customers faster and to accelerate the roadmap more quickly than it could alone. “The combination of MongoDB and Realm will establish the modern standard for mobile application development and data synchronization for a new generation of connected applications and services. MongoDB and Realm are fully committed to investing in the Realm Database and the future of data synchronization, and taking both to the next phase of their evolution,” Ratner wrote in a blog post announcing the deal to customers.
The deal is expected to close in June or July, and the companies are working on integrations and will be announcing details at the MongoDB World customer conference in mid-June.
Google today announced that it has partnered with a number of top open-source data management and analytics companies to integrate their products into its Google Cloud Platform and offer them as managed services operated by its partners. The partners here are Confluent, DataStax, Elastic, InfluxData, MongoDB, Neo4j and Redis Labs.
The idea here, Google says, is to provide users with a seamless user experience and the ability to easily leverage these open-source technologies in Google’s cloud. But there is a lot more at play here, even though Google never quite says so. That’s because Google’s move here is clearly meant to contrast its approach to open-source ecosystems with Amazon’s. It’s no secret that Amazon’s AWS cloud computing platform has a reputation for taking some of the best open-source projects and then forking those and packaging them up under its own brand, often without giving back to the original project. There are some signs that this is changing, but a number of companies have recently taken action and changed their open-source licenses to explicitly prevent this from happening.
That’s where things get interesting, because those companies include Confluent, Elastic, MongoDB, Neo4j and Redis Labs — and those are all partnering with Google on this new project, though it’s worth noting that InfluxData is not taking this new licensing approach and that while DataStax uses lots of open-source technologies, its focus is very much on its enterprise edition.
“As you are aware, there has been a lot of debate in the industry about the best way of delivering these open-source technologies as services in the cloud,” Manvinder Singh, the head of infrastructure partnerships at Google Cloud, said in a press briefing. “Given Google’s DNA and the belief that we have in the open-source model, which is demonstrated by projects like Kubernetes, TensorFlow, Go and so forth, we believe the right way to solve this it to work closely together with companies that have invested their resources in developing these open-source technologies.”
So while AWS takes these projects and then makes them its own, Google has decided to partner with these companies. While Google and its partners declined to comment on the financial arrangements behind these deals, chances are we’re talking about some degree of profit-sharing here.
“Each of the major cloud players is trying to differentiate what it brings to the table for customers, and while we have a strong partnership with Microsoft and Amazon, it’s nice to see that Google has chosen to deepen its partnership with Atlas instead of launching an imitation service,” Sahir Azam, the senior VP of Cloud Products at MongoDB told me. “MongoDB and GCP have been working closely together for years, dating back to the development of Atlas on GCP in early 2017. Over the past two years running Atlas on GCP, our joint teams have developed a strong working relationship and support model for supporting our customers’ mission critical applications.”
As for the actual functionality, the core principle here is that Google will deeply integrate these services into its Cloud Console; for example, similar to what Microsoft did with Databricks on Azure. These will be managed services and Google Cloud will handle the invoicing and the billings will count toward a user’s Google Cloud spending commitments. Support will also run through Google, so users can use a single service to manage and log tickets across all of these services.
Redis Labs CEO and co-founder Ofer Bengal echoed this. “Through this partnership, Redis Labs and Google Cloud are bringing these innovations to enterprise customers, while giving them the choice of where to run their workloads in the cloud, he said. “Customers now have the flexibility to develop applications with Redis Enterprise using the fully integrated managed services on GCP. This will include the ability to manage Redis Enterprise from the GCP console, provisioning, billing, support, and other deep integrations with GCP.”
It’s no secret that remote work and frequent business travel are becoming more and more commonplace. As a result, a growing number of people are shying away from lengthy rental or lease commitments and are instead turning to companies like Blueground for more flexible short-term solutions.
Blueground is trying to be the go-to option for individuals moving or traveling to a city for as little as a month, or any duration longer. Similar to flexible office space providers, Blueground partners with major property owners to sign long-term leases for units it then furnishes and rents out with more flexible terms.
Users can rent listings for anywhere between one month to five years, and rates are set on a monthly basis, which can often lead to more favorable prices over medium-to-long-term stays relative to the short-term pricing structures commonly used by hospitality companies.
Filling hospitality gaps and easing rental friction
CEO Alex Chatzieleftheriou is intimately familiar with the value flexible leasing can unlock. Before founding Blueground, Chatzieleftheriou worked as a consultant for McKinsey, where he was frequently sent off to projects in far-off cities for months at a time — living in 15 cities over just seven years.
However, no matter how much time Alex logged in hotels, he constantly felt the frustration and mental strain of not having a stable personal living arrangement.
“I spent so much time in hotels but they never really resembled a home. They didn’t have enough space or enough privacy,” Chatzieleftheriou told TechCrunch. “But renting an apartment can be a huge pain in these cities. They can be hard to find, they usually have a minimum rental term of a year or more, and you usually have to deal with filling out paperwork and buying furniture.”
Knowing there were thousands of people at his company alone dealing with the same frustrations, Alex launched what would become Blueground, beginning with a handful of apartments in his home city of Athens, Greece.
Chatzieleftheriou and his team structured the platform to make the rental process as seamless as possible for the needs of flexible renters like himself. Through a quick plug-and-play checkout flow — more similar to the booking process for a hotel or Airbnb — renters can lock down an apartment without having to deal with the painful, costly and time-consuming traditional rental process. Tenants are also able to switch to any other Blueground listing during their rental period if their preferences change or if they want to explore different locations during their stay.
Every Blueground listing also comes completely furnished by the company’s design team, so renters don’t have to deal with buying, transporting — and eventually selling — furniture. And each apartment comes outfitted with digital and connected infrastructure so that tenants can monitor their apartment and arrange maintenance, housekeeping and other services directly through Blueground’s mobile app.
The value proposition is also fairly straightforward for the landlords Blueground partners with, as they avoid costs related to marketing and coordinating with fragmented brokers to fill open units, while also benefiting from steady rental payments, tenant vetting and free property management.
The offering certainly seems to be compelling for renters — while Chatzieleftheriou initially focused on serving business travelers and those moving for work, he quickly realized the market for flexible leasing was in fact much bigger. Blueground’s sales have tripled over the past three years and after its expansion in the U.S. last year, Blueground now hosts 1,700 listings in nine cities across three continents.
“The trend of flexible and seamless real estate is bigger and is happening everywhere,” Chatzieleftheriou said. “A lot of people throughout the real estate sector really want this seamless, turnkey, furnished solution.”
To date, Blueground has raised a total of $28 million and plans to use funds from the latest round for additional hiring and to help the company reach its goal of growing its portfolio to 50,000 units over the next five years.
Mike Volpi is a general partner at Index Ventures. Before co-founding the firm's San Francisco office with Danny Rimer, Volpi served as the chief strategy officer at Cisco Systems.
It was just 5 years ago that there was an ample dose of skepticism from investors about the viability of open source as a business model. The common thesis was that Redhat was a snowflake and that no other open source company would be significant in the software universe.
So, why did this movement that once represented the bleeding edge of software become the hot place to be? There are a number of fundamental changes that have advanced open source businesses and their prospects in the market.
David Paul Morris/Bloomberg via Getty Images
From Open Source to Open Core to SaaS
The original open source projects were not really businesses, they were revolutions against the unfair profits that closed-source software companies were reaping. Microsoft, Oracle, SAP and others were extracting monopoly-like “rents” for software, which the top developers of the time didn’t believe was world class. So, beginning with the most broadly used components of software – operating systems and databases – progressive developers collaborated, often asynchronously, to author great pieces of software. Everyone could not only see the software in the open, but through a loosely-knit governance model, they added, improved and enhanced it.
The software was originally created by and for developers, which meant that at first it wasn’t the most user-friendly. But it was performant, robust and flexible. These merits gradually percolated across the software world and, over a decade, Linux became the second most popular OS for servers (next to Windows); MySQL mirrored that feat by eating away at Oracle’s dominance.
The first entrepreneurial ventures attempted to capitalize on this adoption by offering “enterprise-grade” support subscriptions for these software distributions. Redhat emerged the winner in the Linux race and MySQL (thecompany) for databases. These businesses had some obvious limitations – it was harder to monetize software with just support services, but the market size for OS’s and databases was so large that, in spite of more challenged business models, sizeable companies could be built.
The successful adoption of Linux and MySQL laid the foundation for the second generation of Open Source companies – the poster children of this generation were Cloudera and Hortonworks. These open source projects and businesses were fundamentally different from the first generation on two dimensions. First, the software was principally developed within an existing company and not by a broad, unaffiliated community (in the case of Hadoop, the software took shape within Yahoo!) . Second, these businesses were based on the model that only parts of software in the project were licensed for free, so they could charge customers for use of some of the software under a commercial license. The commercial aspects were specifically built for enterprise production use and thus easier to monetize. These companies, therefore, had the ability to capture more revenue even if the market for their product didn’t have quite as much appeal as operating systems and databases.
However, there were downsides to this second generation model of open source business. The first was that no company singularly held ‘moral authority’ over the software – and therefore the contenders competed for profits by offering increasing parts of their software for free. Second, these companies often balkanized the evolution of the software in an attempt to differentiate themselves. To make matters more difficult, these businesses were not built with a cloud service in mind. Therefore, cloud providers were able to use the open source software to create SaaS businesses of the same software base. Amazon’s EMR is a great example of this.
The latest evolution came when entrepreneurial developers grasped the business model challenges existent in the first two generations – Gen 1 and Gen 2 – of open source companies, and evolved the projects with two important elements. The first is that the open source software is now developed largely within the confines of businesses. Often, more than 90% of the lines of code in these projects are written by the employees of the company that commercialized the software. Second, these businesses offer their own software as a cloud service from very early on. In a sense, these are Open Core / Cloud service hybrid businesses with multiple pathways to monetize their product. By offering the products as SaaS, these businesses can interweave open source software with commercial software so customers no longer have to worry about which license they should be taking. Companies like Elastic, Mongo, and Confluent with services like Elastic Cloud, Confluent Cloud, and MongoDB Atlas are examples of this Gen 3. The implications of this evolution are that open source software companies now have the opportunity to become the dominant business model for software infrastructure.
The Role of the Community
While the products of these Gen 3 companies are definitely more tightly controlled by the host companies, the open source community still plays a pivotal role in the creation and development of the open source projects. For one, the community still discoversthe most innovative and relevant projects. They star the projects on Github, download the software in order to try it, and evangelize what they perceive to be the better project so that others can benefit from great software. Much like how a good blog post or a tweet spreads virally, great open source software leverages network effects. It is the community that is the source of promotion for that virality.
The community also ends up effectively being the “product manager” for these projects. It asks for enhancements and improvements; it points out the shortcomings of the software. The feature requests are not in a product requirements document, but on Github, comments threads and Hacker News. And, if an open source project diligently responds to the community, it will shape itself to the features and capabilities that developers want.
The community also acts as the QA department for open source software. It will identify bugs and shortcomings in the software; test 0.x versions diligently; and give the companies feedback on what is working or what is not. The community will also reward great software with positive feedback, which will encourage broader use.
What has changed though, is that the community is not as involved as it used to be in the actual coding of the software projects. While that is a drawback relative to Gen 1 and Gen 2 companies, it is also one of the inevitable realities of the evolving business model.
Linus Torvalds was the designer of the open-source operating system Linux.
Rise of the Developer
It is also important to realize the increasing importance of the developer for these open source projects. The traditional go-to-market model of closed source software targeted IT as the purchasing center of software. While IT still plays a role, the real customers of open source are the developers who often discover the software, and then download and integrate it into the prototype versions of the projects that they are working on. Once “infected”by open source software, these projects work their way through the development cycles of organizations from design, to prototyping, to development, to integration and testing, to staging, and finally to production. By the time the open source software gets to production it is rarely, if ever, displaced. Fundamentally, the software is never “sold”; it is adopted by the developers who appreciate the software more because they can see it and use it themselves rather than being subject to it based on executive decisions.
In other words, open source software permeates itself through the true experts, and makes the selection process much more grassroots than it has ever been historically. The developers basically vote with their feet. This is in stark contrast to how software has traditionally been sold.
Virtues of the Open Source Business Model
The resulting business model of an open source company looks quite different than a traditional software business. First of all, the revenue line is different. Side-by-side, a closed source software company will generally be able to charge more per unit than an open source company. Even today, customers do have some level of resistance to paying a high price per unit for software that is theoretically “free.” But, even though open source software is lower cost per unit, it makes up the total market size by leveraging the elasticity in the market. When something is cheaper, more people buy it. That’s why open source companies have such massive and rapid adoption when they achieve product-market fit.
Another great advantage of open source companies is their far more efficient and viral go-to-market motion. The first and most obvious benefit is that a user is already a “customer” before she even pays for it. Because so much of the initial adoption of open source software comes from developers organically downloading and using the software, the companies themselves can often bypass both the marketing pitch and the proof-of-concept stage of the sales cycle. The sales pitch is more along the lines of, “you already use 500 instances of our software in your environment, wouldn’t you like to upgrade to the enterprise edition and get these additional features?” This translates to much shorter sales cycles, the need for far fewer sales engineers per account executive, and much quicker payback periods of the cost of selling. In fact, in an ideal situation, open source companies can operate with favorable Account Executives to Systems Engineer ratios and can go from sales qualified lead (SQL) to closed sales within one quarter.
This virality allows for open source software businesses to be far more efficient than traditional software businesses from a cash consumption basis. Some of the best open source companies have been able to grow their business at triple-digit growth rates well into their life while maintaining moderate of burn rates of cash. This is hard to imagine in a traditional software company. Needless to say, less cash consumption equals less dilution for the founders.
Photo courtesy of Getty Images
Open Source to Freemium
One last aspect of the changing open source business that is worth elaborating on is the gradual movement from true open source to community-assisted freemium. As mentioned above, the early open source projects leveraged the community as key contributors to the software base. In addition, even for slight elements of commercially-licensed software, there was significant pushback from the community. These days the community and the customer base are much more knowledgeable about the open source business model, and there is an appreciation for the fact that open source companies deserve to have a “paywall” so that they can continue to build and innovate.
In fact, from a customer perspective the two value propositions of open source software are that you a) read the code; b) treat it as freemium. The notion of freemium is that you can basically use it for free until it’s deployed in production or in some degree of scale. Companies like Elastic and Cockroach Labs have gone as far as actually open sourcing all their software but applying a commercial license to parts of the software base. The rationale being that real enterprise customers would pay whether the software is open or closed, and they are more incentivized to use commercial software if they can actually read the code. Indeed, there is a risk that someone could read the code, modify it slightly, and fork the distribution. But in developed economies – where much of the rents exist anyway, it’s unlikely that enterprise companies will elect the copycat as a supplier.
A key enabler to this movement has been the more modern software licenses that companies have either originally embraced or migrated to over time. Mongo’s new license, as well as those of Elastic and Cockroach are good examples of these. Unlike the Apache incubated license – which was often the starting point for open source projects a decade ago, these licenses are far more business-friendly and most model open source businesses are adopting them.
When we originally penned this article on open source four years ago, we aspirationally hoped that we would see the birth of iconic open source companies. At a time where there was only one model – Redhat – we believed that there would be many more. Today, we see a healthy cohort of open source businesses, which is quite exciting. I believe we are just scratching the surface of the kind of iconic companies that we will see emerge from the open source gene pool. From one perspective, these companies valued in the billions are a testament to the power of the model. What is clear is that open source is no longer a fringe approach to software. When top companies around the world are polled, few of them intend to have their core software systems be anything but open source. And if the Fortune 5000 migrate their spend on closed source software to open source, we will see the emergence of a whole new landscape of software companies, with the leaders of this new cohort valued in the tens of billions of dollars.
Clearly, that day is not tomorrow. These open source companies will need to grow and mature and develop their products and organization in the coming decade. But the trend is undeniable and here at Index we’re honored to have been here for the early days of this journey.
The personal details belonging to more than 202 million job seekers in China, including information like phone numbers, email addresses, driver licenses and salary expectations, were freely available to anyone who knew where to look for as long as three years due to an insecure database.
Diachenko, who is director of cyber risk research at Hacken, wasn’t able to match the database with a specific service, but he did locate a three-year-old GitHub repository for an app that included “identical structural patterns as those used in the exposed resumes.” Again, ownership is not clear at this point, although the records do seem to contain data that was scraped from Chinese classifieds, including the Craigslist-like 58.com.
A 58.com spokesperson denied that the records were its creation. They instead claimed that their service had been the victim of scraping from a third-party.
“We have searched all over the database of us and investigated all the other storage, turned out that the sample data is not leaked from us. It seems that the data is leaked from a third party who scrape[d] data from many CV websites,” a spokesperson told Diachenko.
TechCrunch contacted 58.com but we have not yet received a response.
While the database has now been secured, it was potentially vulnerable for up to three years and there’s already evidence that it had been regularly accessed. Although, again, it isn’t clear by whom.
“It’s worth noting that MongoDB log showed at least a dozen IPs who might have accessed the data before it was taken offline,” Diachenko wrote.
There’s plenty of mystery here — it isn’t clear whether 58.com was behind the hole, or if it is a rival service or a scraper — but what is more certain is that the vulnerability is one of the largest of its kind to be found in China.
AWS launchedDocumentDB today, a new database offering that is compatible with the MongoDB API. The company describes DocumentDB as a “fast, scalable, and highly available document database that is designed to be compatible with your existing MongoDB applications and tools.” In effect, it’s a hosted drop-in replacement for MongoDB that doesn’t use any MongoDB code.
AWS argues that while MongoDB is great at what it does, its customers have found it hard to build fast and highly available applications on the open-source platform that can scale to multiple terabytes and hundreds of thousands of reads and writes per second. So what the company did was build its own document database, but made it compatible with the Apache 2.0 open source MongoDB 3.6 API.
If you’ve been following the politics of open source over the last few months, you’ll understand that the optics of this aren’t great. It’s also no secret that AWS has long been accused of taking the best open-source projects and re-using and re-branding them without always giving back to those communities.
The wrinkle here is that MongoDB was one of the first companies that aimed to put a stop to this by re-licensing its open-source tools under a new license that explicitly stated that companies that wanted to do this had to buy a commercial license. Since then, others have followed.
“Imitation is the sincerest form of flattery, so it’s not surprising that Amazon would try to capitalize on the popularity and momentum of MongoDB’s document model,” MongoDB CEO and president Dev Ittycheria told us. “However, developers are technically savvy enough to distinguish between the real thing and a poor imitation. MongoDB will continue to outperform any impersonations in the market.”
That’s a pretty feisty comment. Last November, Ittycheria told my colleague Ron Miller that he believed that AWS loved MongoDB because it drives a lot of consumption. In that interview, he also noted that “customers have spent the last five years trying to extricate themselves from another large vendor. The last thing they want to do is replay the same movie.”
MongoDB co-founder and CTO Eliot Horowitz echoed this. “In order to give developers what they want, AWS has been pushed to offer an imitation MongoDB service that is based on the MongoDB code from two years ago,” he said. “Our entire company is focused on one thing — giving developers the best way to work with data with the freedom to run anywhere. Our commitment to that single mission will continue to differentiate the real MongoDB from any imitation products that come along.”
A company spokesperson for MongoDB also highlighted that the 3.6 API that DocumentDB is compatible with is now two years old and misses most of the newest features, including ACID transactions, global clusters and mobile sync.
To be fair, AWS has become more active in open source lately and, in a way, it’s giving developers what they want (and not all developers are happy with MongoDB’s own hosted service). Bypassing MongoDB’s licensing by going for API comparability, given that AWS knows exactly why MongoDB did that, was always going to be a controversial move and won’t endear the company to the open-source community.
There’s a dark cloud on the horizon. The behavior of cloud infrastructure providers, such as Amazon, threatens the viability of open source. I first wrote about this problem in a prior piece on TechCrunch. In 2018, thankfully, several leaders have mobilized (amid controversy) to propose multiple solutions to the problem. Here’s what’s happened in the last month.
Go to Amazon Web Services (AWS) and hover over the Products menu at the top. You will see numerous open-source projects that Amazon did not create, but run as-a-service. These provide Amazon with billions of dollars of revenue per year. To be clear, this is not illegal. But it is not conducive to sustainable open-source communities, and especially commercial open-source innovation.
In early 2018, I gathered together the creators, CEOs or general counsels of two dozen at-scale open-source companies, along with respected open-source lawyer Heather Meeker, to talk about what to do.
We wished to define a license that prevents cloud infrastructure providers from running certain software as a commercial service, while at the same time making that software effectively open source for everyone else, i.e. everyone not running that software as a commercial service.
With our first proposal, Commons Clause, we took the most straightforward approach: we constructed one clause, which can be added to any liberal open-source license, preventing the licensee from “Selling” the software — where “Selling” includes running it as a commercial service. (Selling other software made with Commons Clause software is allowed, of course.) Applying Commons Clause transitions a project from open source to source-available.
We also love the proposal being spearheaded by another participant, MongoDB, called the Server Side Public License (SSPL). Rather than prohibit the software from being run as a service, SSPL requires that you open-source all programs that you use to make the software available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service. This is known as a “copyleft.”
These two licenses are two different solutions to exactly the same problem. Heather Meeker wrote both solutions, supported by feedback organized by FOSSA.
In October, one of the board members of the Apache Software Foundation (ASF) reached out to me and suggested working together to create a modern open-source license that solves the industry’s needs.
Kudos to MongoDB
Further kudos are owed to MondoDB for definitively stating that they will be using SSPL, submitting SSPL in parallel to an organization called Open Source Initiative (OSI) for endorsement as an open-source license, but not waiting for OSI’s endorsement to start releasing software under the SSPL.
OSI, which has somehow anointed itself as the body that will “decide” whether a license is open source, has a habit of myopically debating what’s open source and what’s not. With the submission of SSPL to OSI, MongoDB has put the ball in OSI’s court to either step up and help solve an industry problem, or put their heads back in the sand.
In fact, MongoDB has done OSI a huge favor. MongoDB has gone and solved the problem and handed a perfectly serviceable open-source license to OSI on a silver platter.
The public archives of OSI’s debate over SSPL are at times informative and at times amusing, bordering on comical. After MongoDB’s original submission, there were rah-rah rally cries amongst the members to find reasons to deem SSPL not an open-source license, followed by some +1’s. Member John Cowanreminded the group that just because OSI does not endorse a license as open source, does not mean that it is not open source:
As far as I know (which is pretty far), the OSI doesn’t do that. They have never publicly said “License X is not open source.” People on various mailing lists have done so, but not the OSI as such. And they certainly don’t say “Any license not on our OSI Certified ™ list is not open source”, because that would be false. It’s easy to write a license that is obviously open source that the OSI would never certify for any of a variety of reasons.
Eliot Horowitz (CTO and co-founder of MongoDB) responded cogently to questions, comments and objections, concluding with:
In short, we believe that in today’s world, linking has been superseded by the provision of programs as services and the connection of programs over networks as the main form of program combination. It is unclear whether existing copyleft licenses clearly apply to this form of program combination, and we intend the SSPL to be an option for developers to address this uncertainty.
Heather Meeker (the lawyer who drafted both Commons Clause and SSPL) stepped in and completely addressed the legal issues that had been raised thus far. Various other clarifications were made by Eliot Horowitz, and he also conveyed willingness to change the wording of the license if it would help.
Discussion amongst the members continued about the role, relevance and purpose of OSI, with one member astutely noting that there were a lot of “free software” wonks in the group, attempting to bastardize open source to advocate their own agenda:
If, instead, OSI has decided that they are now a Free Software organization, and that Free Software is what “we” do, and that “our” focus is on “Free software” then, then let’s change the name to the Free Software Initiative and open the gates for some other entity, who is all about Open Source, to take on that job, and do it proudly. :-)
There was debate over whether SSPL discriminates against types of users, which would disqualify it from being open source. Eliot Horowitz provided a convincing explanation that it did not, which seemed to quiet the crowd.
We’re not falling on our swords because of this. And we can fix OSD #9 with a two word addition “or performed” as soon as the board can meet. But it’s annoying.
Kyle Mitchell, himself an accomplished open-source lawyer, opposed such a tactic. Larry Rosen pointed out that some members’ assertion (that “it is fundamental to open source that everyone can use a program for any purpose”) is untrue. Still more entertaining discussion ensued about the purpose of OSI and the meaning of open source.
Carlos Piana succinctly stated why SSPL was indeed open source. Kyle Mitchell added that if licenses were to be judged in the manner that the group was judging SSPL, then GPL v2 was not open source either.
Meanwhile Dor Lior, the founder of database company ScyllaDB, compared SSPL and AGPL side-to-side and argued that “MongoDB would have been better off with Commons Clause or just swallowed a hard pill and stayed with APGL.” Player.FM released their service based on Commons Clause-licensed RediSearch, after in-memory database company Redis Labs placed RediSearch and four other specific add-on modules (but not Redis itself) under Commons Clause, and graph database company Neo4J placed its enterprise codebase under Commons Clause and raised an $80 million Series E.
Then Michael DeHaan, creator of Red Hat Ansible, chose Commons Clause for his new project. When asked why he did not choose any of the existing licenses that OSI has “endorsed” to be open source, he said:
This groundswell in 2018 should be ample indication that there is an industry problem that needs to be fixed.
Eliot Horowitz summarized and addressed all the issues, dropped the mic and left for a while. When it seemed like SSPL was indeed following all the rules of open-source licenses, and was garnering support of the members, Brad Kuhn put forward a clumsy argument for why OSI should change the rules as necessary to prevent SSPL from being deemed open source, concluding:
It’s likely the entire “license evaluation process” that we use is inherently flawed.
OSI has 60 days since MongoDB’s new submission to make a choice:
Wake up and realize that SSPL, perhaps with some edits, is indeed an open-source license, OR
Effectively signal to the world that OSI does not wish to help solve the industry’s problems, and that they’d rather be policy wonks and have theoretical debates.
“Wonk” here is meant in the best possible way.
Importantly, MongoDB is proceeding to use the SSPL regardless. If MongoDB were going to wait until OSI’s decision, or if OSI were more relevant, we might wait with bated breath to hear whether OSI would endorse SSPL as an open-source license.
As it stands, OSI’s decision is more important to OSI itself than to the industry. It signals whether OSI wants to remain relevant and help solve industry problems or whether it has become too myopic to be useful. Fearful of the latter, we looked to other groups for leadership and engaged with the Apache Software Foundation (ASF) when they reached out in the hopes of creating a modern open-source license that solves the industry’s needs.
OSI should realize that while it would be nice if they deemed SSPL to be open source, it is not critical. Again in the words of John Cowan, just because OSI has not endorsed a license as open source, does not mean it’s not open source. While we greatly respect almost all members of industry associations and the work they do in their fields, it is becoming difficult to respect the purpose and process of any group that anoints itself as the body that will “decide” whether a license is open source — it is arbitrary and obsolete.
In my zest to urge the industry to solve this problem, in an earlier piece, I had said that “if one takes open source software that someone else has built and offers it verbatim as a commercial service for one’s own profit” (as cloud infrastructure providers do) that’s “not in the spirit” of open source. That’s an overstatement and thus, frankly, incorrect. Open source policy wonks pointed this out. I obviously don’t mind rattling their cages but I should have stayed away from making statements about “what’s in the spirit” so as to not detract from my main argument.
The behavior of cloud infrastructure providers poses an existential threat to open source. Cloud infrastructure providers are not evil. Current open-source licenses allow them to take open-source software verbatim and offer it as a commercial service without giving back to the open-source projects or their commercial shepherds. The problem is that developers do not have open-source licensing alternatives that prevent cloud infrastructure providers from doing so. Open-source standards groups should help, rather than get in the way. We must ensure that authors of open-source software can not only survive, but thrive. And if that means taking a stronger stance against cloud infrastructure providers, then authors should have licenses available to allow for that. The open-source community should make this an urgent priority.
MongoDB is a bit miffed that some cloud providers — especially in Asia — are taking its open-source code and offering a hosted commercial version of its database to their users without playing by the open-source rules. To combat this, MongoDB today announced it has issued a new software license, the Server Side Public License (SSPL), that will apply to all new releases of its MongoDB Community Server, as well as all patch fixes for prior versions.
Previously, MongoDB used the GNU AGPLv3 license, but it has now submitted the SSPL for approval from the Open Source Initiative.
For virtually all regular users who are currently using the community server, nothing changes because the changes to the license don’t apply to them. Instead, this is about what MongoDB sees as the misuse of the AGPLv3 license. “MongoDB was previously licensed under the GNU AGPLv3, which meant companies who wanted to run MongoDB as a publicly available service had to open source their software or obtain a commercial license from MongoDB,” the company explains. “However, MongoDB’s popularity has led some organizations to test the boundaries of the GNU AGPLv3.”
So while the SSPL isn’t all that different from the GNU GPLv3, with all the usual freedoms to use, modify and redistribute the code (and virtually the same language), the SSPL explicitly states that anybody who wants to offer MongoDB as a service — or really any other software that uses this license — needs to either get a commercial license or open source the service to give back the community.
“The market is increasingly consuming software as a service, creating an incredible opportunity to foster a new wave of great open source server-side software. Unfortunately, once an open source project becomes interesting, it is too easy for cloud vendors who have not developed the software to capture all of the value but contribute nothing back to the community,” said Eliot Horowitz, the CTO and co-founder of MongoDB, in a statement. “We have greatly contributed to — and benefited from — open source and we are in a unique position to lead on an issue impacting many organizations. We hope this will help inspire more projects and protect open source innovation.”
I’m sure this move will ruffle some feathers. It’s hard to discuss open-source licenses without getting religious about what this movement is all about. And because MongoDB is the commercial entity behind the software and manages outside contributions to the code, it does have a stronger grip on the actual code than other projects that are managed by a large open-source foundation, for example. For some, that alone is anathema to everything they think open source should stand for. For others, it’s simply a pragmatic way to develop software. Either way, though, this will kick off a discussion about how companies like MongoDB manage their open-source projects and how much control they can exert over how their code is used. I, for one, can’t wait to read the discussions on Hacker News today.
Navionics, an electronic navigational chart maker owned by tech giant Garmin, has secured an exposed database that contained hundreds of thousands of customer records.
The MondoDB database wasn’t secured with a password, allowing anyone who knew where to look to access and download the data.
The company’s main products give boat, yacht and ship owners better access to real-time navigation charts, and boasts the “world’s largest cartography database.”
Bob Diachenko, Hacken.io’s newly appointed director of cyber risk research, said in a blog post that the 19 gigabyte database contained 261,259 unique records, including customer names and email addresses. The data also and information about their boat — such as latitude and longitude, boat speed and other navigational details — which Diachenko said likely updating in real-time.
After Diachenko contacted the company, Navionics shut down the server.
A Navionics spokesperson confirmed the breach. “Once notified, we immediately investigated and resolved the vulnerability,” the spokesperson said. “Following our investigation, we confirmed that none of the records or data were otherwise accessed or exfiltrated, and none of the data was lost.”
Navionics began notifying customers Monday.
It’s the latest in a string of MongoDB -based exposures. For years, the database was designed to sit behind firewalls and was not automatically password protected. Since more database have become connected directly to the internet, MongoDB refreshed its software to include a password by default. But many outdated installations are still unsecured.
Many exposed MongoDB databases have been accessed by hackers, had their contents downloaded and then wiped, and held to ransom.
Cosmos DB is undoubtedly one of the most interesting products in Microsoft’s Azure portfolio. It’s a fully managed, globally distributed multi-model database that offers throughput guarantees, a number of different consistency models and high read and write availability guarantees. Now that’s a mouthful, but basically, it means that developers can build a truly global product, write database updates to Cosmos DB and rest assured that every other user across the world will see those updates within 20 milliseconds or so. And to write their applications, they can pretend that Cosmos DB is a SQL- or MongoDB-compatible database, for example.
CosmosDB officially launched in May 2017, though in many ways it’s an evolution of Microsoft’s existing Document DB product, which was far less flexible. Today, a lot of Microsoft’s own products run on CosmosDB, including the Azure Portal itself, as well as Skype, Office 365 and Xbox.
Today, Microsoft is extending Cosmos DB with the launch of its multi-master replication feature into general availability, as well as support for the Cassandra API, giving developers yet another option to bring existing products to CosmosDB, which in this case are those written for Cassandra.
Microsoft now also promises 99.999 percent read and write availability. Previously, it’s read availability promise was 99.99 percent. And while that may not seem like a big difference, it does show that after more of a year of operating Cosmos DB with customers, Microsoft now feels more confident that it’s a highly stable system. In addition, Microsoft is also updating its write latency SLA and now promises less than 10 milliseconds at the 99th percentile.
“If you have write-heavy workloads, spanning multiple geos, and you need this near real-time ingest of your data, this becomes extremely attractive for IoT, web, mobile gaming scenarios,” Microsoft CosmosDB architect and product manager Rimma Nehme told me. She also stressed that she believes Microsoft’s SLA definitions are far more stringent than those of its competitors.
The highlight of the update, though, is multi-master replication. “We believe that we’re really the first operational database out there in the marketplace that runs on such a scale and will enable globally scalable multi-master available to the customers,” Nehme said. “The underlying protocols were designed to be multi-master from the very beginning.”
Why is this such a big deal? With this, developers can designate every region they run Cosmos DB in as a master in its own right, making for a far more scalable system in terms of being able to write updates to the database. There’s no need to first write to a single master node, which may be far away, and then have that node push the update to every other region. Instead, applications can write to the nearest region, and Cosmos DB handles everything from there. If there are conflicts, the user can decide how those should be resolved based on their own needs.
Nehme noted that all of this still plays well with CosmosDB’s existing set of consistency models. If you don’t spend your days thinking about database consistency models, then this may sound arcane, but there’s a whole area of computer science that focuses on little else but how to best handle a scenario where two users virtually simultaneously try to change the same cell in a distributed database.
Unlike other databases, Cosmos DB allows for a variety of consistency models, ranging from strong to eventual, with three intermediary models. And it actually turns out that most CosmosDB users opt for one of those intermediary models.
Interestingly, when I talked to Leslie Lamport, the Turing award winner who developed some of the fundamental concepts behind these consistency models (and the popular LaTeX document preparation system), he wasn’t all that sure that the developers are making the right choice. “I don’t know whether they really understand the consequences or whether their customers are going to be in for some surprises,” he told me. “If they’re smart, they are getting just the amount of consistency that they need. If they’re not smart, it means they’re trying to gain some efficiency and their users might not be happy about that.” He noted that when you give up strong consistency, it’s often hard to understand what exactly is happening.
But strong consistency comes with its drawbacks, too, which leads to higher latency. “For strong consistency there are a certain number of roundtrip message delays that you can’t avoid,” Lamport noted.
The CosmosDB team isn’t just building on some of the fundamental work Lamport did around databases, but it’s also making extensive use of TLA+, the formal specification language Lamport developed in the late 90s. Microsoft, as well as Amazon and others, are now training their engineers to use TLA+ to describe their algorithms mathematically before they implement them in whatever language they prefer.
“Because [CosmosDB is] a massively complicated system, there is no way to ensure the correctness of it because we are humans, and trying to hold all of these failure conditions and the complexity in any one person’s — one engineer’s — head, is impossible,” Microsoft Technical Follow Dharma Shukla noted. “TLA+ is huge in terms of getting the design done correctly, specified and validated using the TLA+ tools even before a single line of code is written. You cover all of those hundreds of thousands of edge cases that can potentially lead to data loss or availability loss, or race conditions that you had never thought about, but that two or three years ago after you have deployed the code can lead to some data corruption for customers. That would be disastrous.”
“Programming languages have a very precise goal, which is to be able to write code. And the thing that I’ve been saying over and over again is that programming is more than just coding,” Lamport added. “It’s not just coding, that’s the easy part of programming. The hard part of programming is getting the algorithms right.”
Lamport also noted that he deliberately chose to make TLA+ look like mathematics, not like another programming languages. “It really forces people to think above the code level,” Lamport noted and added that engineers often tell him that it changes the way they think.
As for those companies that don’t use TLA+ or a similar methodology, Lamport says he’s worried. “I’m really comforted that [Microsoft] is using TLA+ because I don’t see how anyone could do it without using that kind of mathematical thinking — and I worry about what the other systems that we wind up using built by other organizations — I worry about how reliable they are.”