Two weeks ago I submitted the second version of the Server Side Public License (SSPL) to the OSI for review. The revision was based on feedback from the OSI license-review mailing list, which highlighted areas in the first version that would benefit from clarification. We think open source is important, which is why we chose to remain open source with the SSPL, as opposed to going proprietary or source-available. I am hopeful that the SSPL will also be declared an OSI-approved license, because the business conditions that prompted MongoDB to issue the SSPL are not unique to us and I believe the SSPL can lead to a new era of open source investment.
I wrote an email to my team addressing the anti-diversity-effort memo.
One of the most important things an organization can do as it grows out of startup-hood to maturity is to learn to run parallel engineering efforts. A parallel set of projects might implement multiple takes on an overall idea, testing out different approaches. Or it might implement the same idea at multiple points on a time/quality tradeoff continuum: a low-effort, easily delivered prototype, and a more fleshed-out version that takes longer to deliver.
On November 1st, 2016, I gave a talk at the CTO Summit series hosted by NASDAQ. It was a 20 minute talk, updating and expanding on a topic I’ve both blogged and written articles about – how important it is for engineering managers to keep their hands in the codebase they make decisions about. Here it is:
Last week I was in Israel for the MongoDBeer meetup and an enterprise event, both hosted by Matrix, one of our partners, and a few really great client meetings. One of the things that I don’t get to do often enough these days is work directly with customers on interesting technical challenges, so those client meetings were really quite invigorating. I was reminded of this recently when I was doing a fireside chat with Albert Wenger at NYCode, an event hosted by NextView Ventures.
Back on April 25th I spoke at dotScale in Paris; I gave a talk called “The Case for Cross-Service Joins,” as in queries that join data across multiple 3rd party services. For example, analytics over data that comes from both SalesForce and Googe Analytics. I’ve been thinking a lot about this topic, because MongoDB sits at the middle of a lot of apps that utilize 3rd-party services, and the benefits of building your app on top of such services comes at the cost of that data being siloed away, and difficult analyze it in a holistic way.
One theme I kept harping on at MongoDB World a few weeks ago was knowing when to innovate around new ideas and when to just reuse what already works well for products that have been successful. This comes up continuously at MongoDB, because having a good understanding of it is a significant competitive advantage. I attribute a large extent of MongoDB’s success to our unbending adherence to this discipline. When we started MongoDB, we had a clear goal - make data and databases easier for developers and operators, so that data and databases serve their users, not the other way around.
Almost all modern applications are composed of presentation layers, services executing business logic, and backing stores where the data resides. Developers could be more productive and agile if they could work more directly with the backing data without having to build specific APIs for every access type, but is quite a challenging problem. An emerging class of solution known as Backend as a Service (BaaS) has tried to address this problem over the last few years, but hasn’t become the norm yet.