

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<p>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.<p>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.<p>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
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
Please contact me - I would love to discuss. [username] at NoSQL dot com

