How to market my NoSQL technology

[tom_andersson]

I have been developing a technology which best can be described as an object oriented / graph NoSQL database, and I need some ideas on how to market it. Check out my web site at: http://www.clear-objects.com/clearodb

The end users would be software developers who writes distributed applications. I haven't thought to much about it's use for web site development, but maybe that could work too.

I am a bit lost as to what approach to take to get this out. I think, the best way is to somehow find individual users who can see the value and that way step by step build up a customer base. I don't think open source is necessarily the way to go (in my life as a professional developer, I have never made a decision to use a technology based on whether it is open source or not, but rather whether it will save me time). I guess the main problem is to convince people that this technology will save them time.

Questions: - Anyone who has launched products to a similar market who has any experiences to share? - Any thoughts on whether an open or closed source approach is better? Would I be more successful in making money long term, if I have a large number of users who use it for free? - I don't really want to sell this as a database technology, but rather a cost saving tool for creating distributed applications (that was really the problem I tried to solve in the first place, it just turned out to be a graph database). Any thoughts on this?

[opendomain]

There are over 100 different NoSQL databases - so you have to definately show something on how your software is better. Most NoSQL are open sourced and are free to use for limited installs, so it will be very hard to make money with licensing. Some offer a base version for free, but offer clustering or other advanced features at a cost. Some charge money for consulting. Where does your db sit on the CAP spectrum? How is it the best for a specific use case?

[tom_andersson → opendomain]

Yeah, I realise there are quite a few nosqls around. But only a few have just recently started to gain momentum. It is still very easy to find developers who have never heard of anything but traditional relational databases (not sure if I would dare to say the majority of all developers). In most cases relational databases is the best option for what they are doing, but I think there are many situations where people choose the old sql just because they don't know better. So, although there might be a point in comparing and competing between different NoSQL technologies, I think all within the NoSQL movement can gain from better marketing to all these relational database users.

Anyway, I think what you are saying is I need to be very good at describing why my technology is better than others, which as a developer I find very difficult. It is easy to be technical about it, but how to describe something at a level that makes sense to the average guy is something I am still trying to learn.

What my solution does very well is integration with object oriented languages and where the data is described by complex inheritance structures and ownership relations (say a financial model with different types of financial instruments, different types of market data, static data, deal data, etc which would be described by a number of class hierarchies; and all linked together).

With the risk of getting too technical, if you are building a C++ application for example, you only create your C++ classes (with any inheritance structure which can be single/multiple etc), and you can use pointers to other objects (polymorphic pointers and cyclic graphs are ok), use standard collection classes etc. Basically what you would normally do when designing a C++ application. You use a minimum amount of declarative code as C++ doesn't have built-in reflection. You send your C++ classes to the database and receive the data as your C++ classes. It traverses your objects to find all linkages to other objects prior to sending and links objects together upon retrieval. In short, the solution tries to make life as easy as possible for an application programmer.

What my solution does in terms of CAP and ACID: Atomicity - A transaction is either committed in full or not at all. A transaction may consist of one or multiple objects.

Consistency - No consistency checks in the sense that there are defined constraints on the member fields. However, all objects are versioned, and if two clients are trying to commit the same version of an object, the second client will fail and it would have to retrieve the most recent version before updating the object.

Isolation - All transactions are processed in isolation, i.e. all objects in a transaction are locked prior to being updated

Durability - Transactions are never overwritten, i.e. new transactions are always added to the end of the data store. If a transaction has completed successfully, you can be certain that the transaction will be completed even after a server crash.

Availability - Concurrency is handled by locking objects. Many clients can read simultaneously, but if you try to read an object that is locked for writing by someone else, you will have to wait (there is room for improvement here). If you try to write to an object that someone else is writing to, you will fail. I have not looked into performance of a large number of clients, however the simple answer is that consistency is prioritised above availability.

Partition Tolerance - None at the moment. I have not looked into distributing the database yet.

[opendomain → tom_andersson]

Please contact me - I would love to discuss. [username] at NoSQL dot com