If you watched short movies about Robomongo, you probably know that I’m broken off between Robomongo and my position at Paralect. Today it is evident to me, that I’m not able to support and develop Robomongo alone anymore.
Today, I’m taking my last attempt to rescue the project. My goal is to create a team of C/C++ Developer and QA Engineer who can work on the project at Paralect office without being distracted to anything else for one year. One year is a sufficient term to not only solve most of current major issues, but also it will be enough to implement number of new features. With a focus on a single project we could really stir up Robomongo and not only solve most of current major issues, but also implement a number of important new features. In order for this to happen, we need your support!
Despite everything, even today, Robomongo is very popular. If you open Google Trends and compare the most notable MongoDB UIs, you will get this:
This blue line is Robomongo.
Today we have many MongoDB administration interfaces, but Robomongo so far is the only tool that is so deeply integrated with MongoDB’s mongo shell, that it even embeds it. If you are familiar with MongoDB shell — then you already know how to work with Robomongo. If you are new to MongoDB shell, Robomongo is the best way to learn it.
The reason why such deep integration with mongo shell is not implemented in other tools — complexity. Each new version of MongoDB has new version of mongo shell, that should be integrated with Robomongo. Integration is not as straightforward as it seems and requires changes of MongoDB source code. Even JavaScript engine, used by MongoDB, was changed twice. Starting from the version 2.4, MongoDB began to use Google V8 engine, instead of SpiderMonkey. But in MongoDB 3.2 SpiderMonkey is back again. Now we cannot be sure, what is a safe bet for JavaScript engine for Robomongo. Should we just support SpiderMonkey, V8 or both? All these mean, that significant efforts are required to support “#1 feature” of Robomongo.
The current model of Robomongo distribution is also requires changes. Today we bundle Robomongo with a single version of MongoDB shell and you are lucky if it supports your version of MongoDB. That is why one of the important features that should be implemented is a pluggable Robomongo engine:
The API between Robomongo GUI and Engine should be defined. And such engines should be moved to separate projects. Each time you decide to connect to some MongoDB cluster, you will be able to select needed version of pluggable Robomongo Engine.
Now add to all of this cross-platform and native nature of Robomongo, and you will quickly realize how many efforts are needed to deliver this tool to your laptop with Mac/Windows/Linux of version N. A rigorous quality assurance alone requires a dedicated person.
Plan for next 6 months
We are planning to address 7 major features in the first 6 months. According to Magic Backlog, these features are the most requested by the community.
1. Support for MongoDB 3.x storages (WiredTiger and others)
From version 3.0 MongoDB introduces new pluggable storage architecture and the WiredTiger storage engine. Currently Robomongo only supports MMAPv1 storage engine. From version 3.2 MongoDB starts to use WiredTiger by default. We plan to add support for WiredTiger first and work on other storage engines, such as In Memory and Encrypted storages right after.
2. Support for V8 JavaScript engine
At the moment, Robomongo is based on the SpiderMonkey JavaScript engine. Since MongoDB 2.3.1, JavaScript engine was changed from SpiderMonkey to Google V8. But starting from 3.1.9 MongoDB is based on SpiderMonkey again. To support all versions of the MongoDB we need to implement V8 JavaScript engine and this is quite a lot of work. MongoDB 3.2 soon will be a production-ready release and we plan to focus on that release first, while still considering support for all versions of MongoDB.
3. Support for Replica Sets
The support of the Replica Sets is one of the most awaiting features. This feature, along with two above, are our first priority and should cover needs of the major part of the Robomongo community.
4. In-place edit when in tree or table view
We think, that in place edit is the one of the best UX improvements we can make. This improvement should make use of Robomongo more efficient than its ever been.
5. Copying of documents, collections and databases
Copying documents, collections and databases are operations which are used very often in development and production. We want to add proper support for them.
6. Export and import to/from JSON and CSV
We want to add a quick way of sharing MongoDB data with the others. Initially we are planning to add basic import/exports support, later we are planing to integrate with MongoDB tools more deeply.
7. Better GridFS support
Although we think that GridFS is not the feature that is used by most MongoDB users, but we still are planning to implement fast files view with ability to create, edit and delete files.
This Robomongo mascot is new and was never used with Robomongo. We are planning to use it for the next versions. It was designed by Gabriel Bernal from Colombia and he asked to implement support for MongoDB v3.0 in return for it.
I would like to say a big thank you to Stephen Steneker, MongoDB Community Support Manager, who helped Robomongo so much. It is impossible to explain in one post all he had done for the project. Stephen is the #2 contributor to Robomongo. Stephen’s volunteer efforts are a great example of contributing to open source projects and community, and helped maintain interest in the Robomongo project.
Thank you to all Robomongo contributors and users!
Starting from today, Magic Backlog will be deactivated. If campaign doesn’t succeed and thus Robomongo development stops, we will return all Magic Backlog’s donations to everybody who will ask us. This will be our final thank you for your belief in us.
Next 60 days will decide the future of Robomongo. After these days landscape of MongoDB tools will either receive strong player back, or loose it.