I’ve been thinking a lot about whether I needed to write this and decided I should. These are some generic thoughts with regards to your product and not related to any person in particular and are not meant to be offensive in any way.

The story start a few years back when I by a chance made a discovery of a new product that changed my view on an OR/M in general. I’m talking about DO 3.x right now. It’s been indeed like a breath of fresh air in comparison to what I’ve been used to. Though many people I knew did not understand/support this way of managing your database I’ve become a fan of your product from the day one.

And so some years passed by and looking back at that I have some thoughts I’d like to share with you about what I like and don’t like about DataObjects.Net.

First of all what I really like:

  • The product of course!!! It’s still one of most innovating OR/M mappers I’ve come across. Really good job guys!

  • Support is awesome as well. It’s prompt and to the point. Nothing else to add.

  • Your vision guys… to some extend though and this is why

Things I don’t really like

  • Constant change of plans. Frankly speaking it’s just drives me crazy. I’ve been trying to follow your roadmap for some time already and it’s just impossible. First you’ve been publishing the upcoming changes on the wiki pages but right now it has not been updated for a while. Then I’ve made a switch to the source repository and to be exact your TODO.txt file. Once more it’s a dead end again. Even your site provides and outdated information, like legacy databases, localization, access control system:

http://www.x-tensive.com/Products/DO/Default.aspx

The only kind of reliable source of the upcoming changes is your blog. But here as well, so many ideas and proposals were mentioned in the past year, it’s kind of difficult to predict what’s going to happened.

And this is actually bad. A few times I’ve made a proposal of your product to the companies I’ve been working for. And each time it happened that a feature they requested was just about to be implemented, at least what the site/blog/wiki was saying. What happened next? Change of plans again… Still not really functioning legacy support, no synchronization implementation no GUI tools to support your product.

  • The manual, sadly it’s still incomplete. Some basic stuff like FullText or Precision FieldAttributes descriptions and examples and more advanced like O2O mapper.

  • User-friendliness of the product. As you know the user-friendliness of a product is a key factor for a success. Don’t want to offend anyone but one of the examples would be Linux vs Windows. Linux is still a niche product, though it more secure and stable. User friendliness is also a good selling point. Many of the managers out there are just crazy about the tools. Point and click sells good. And it will give your product and extra strength, like NHibernate Profiler.

  • The penetration of the market. The product is not as well-known as some of your competitors. Something I think needs to be done about it. You product has a lot to offer but not many people are aware of that.

Once more I’d like to stress out that this post is meant to be a feedback from one of your customers. Thanks.


Updated at 21.06.2010 22:32:08

Thank you for being honest here. Frankly speaking I thought you would not like this kind of posts being published here :-)

Anyway I don’t want to be the one who tells how to run the show I’m more than confident that you know this already. The only hope I have that DO will not lose its uniqueness and become just one of many. There’re indeed the ones who just follow the trend but there’re also who prefer to think differently and I prefer to belong to the second group. So please don’t change your product drastically…

The next few lines are just some, maybe silly, thoughts I have after reading your response…

  • As you were mentioning concentrating in the first place on the requests from the paying customers it’s not always the right path? I can imagine that “sacrificing” these requests for a greater good can be and should be justified.
  • Maybe it’s an idea to start working with partners? Don’t want to discuss any financial aspects of that but this way you could concentrate on things you do the best and leave the “dirty” job to the people who know the (local) market?
  • After a small polishing round publishing an article in one of the magazines could help as well I would think.

Anyway I was just thinking aloud here, maybe the others will have some suggestions?

This thread was imported from our support forum. The original discussion may contain more detailed answer. Original topic by samirski.

asked Jun 19 '10 at 10:45

Editor's gravatar image

Editor
46154156157


One Answer:

I thought for pretty long time before answering here. Actually, you're absolutely right - DO4 is a mix of both good and bad practices, and it's pretty hard for us to follow the right path. I'll try to explain why some of mentioned issues happen - obviously, not to left this "as is", but may be, to get some advices.

So:

1. Penetration of the market: that's the most important part here. Currently we run mainy AdWords campaigns - shortly budget there will be noticeably extended, but anyway, direct advertisement is just a part of the problem. Another one is articles and publications based on short examples: it looks like either I (or someone else from our team with acceptable English, e.g. Dmitry Maximov), should dedicate all the time for this or this simply won't move. Blog posts by people using DO actually aren't effecient: developers like examples.

On the other hand, I still spend a lot of time on product development. Switching to articles & examples will stop this activity. Actually, I already tried to do this when announced Xtensive.Practices, but finally we all returned back to development & bugfixes (yes, there are many bug reports as well).

Imagine you're @ my place, and your resources are limited. So what should I prefer - to switch mainly on article writing (this will attract new customers), or to work on features (this is important for existing ones)? First option is logically better; but I still follow the second one - may be because I tend to promise too much (as marketing\sales guy :) ).

If you have anything to add here, I'd be glad to listen.

2. User-friendliness of the product. This is one more big problem we have, and actually it is quite related to 1. The product is intrinsically complex - i.e. although APIs are pretty simple, you should know lots of details (e.g. how lazy loading really works, what are transactional methods, etc.) to use them. Obviously, this isn't good: lots of developers dislike the idea of investing e.g. 2 weeks on just studying the framework, and actually it doesn't matter that you'll finally get similar case with competitors.

Simple problems must be solved by simple, and moreover, expected ways. In our case this isn't true:

  • Most of people expect ORM supports either ActiveRecord or provides GUI mapper. In our case none of these ways is supported - we're unique ;)
  • Most of people expect POCO-like behavior from ORM. Again, this isn't true in our case, and it does't matter what are the benefits of approach we offer.
  • There are some other pretty unexpected concepts in our case - e.g. activation, current Session, schema upgrade.

I tend to think it was a mistake to design such a machine from scratch - we should really try to provide POCO+T4 version first, and grow it up to nearly current state further. Partially, because of this we waste our time on bugfixes - there are lots of features, people tend to use them, and as usual, there are some bugs.

Anyway, it's already clear for us that we can't change the way people think. So we should change our APIs, or, more likely, provide additional ones allowing people to use the product according to their expectations. So the list of simplifications we're going to implement soon includes:

  • POCO support. Don't ask about details - I'll dedicate a special post for this later.
  • Legacy mode improvements: IDENTITY column support, DTO mapping to views and stored procedures.
  • T4-based model code generation (ActiveRecord pattern).

Note: currently this isn't planned, i.e. I just described thoughts we have here. This will be announced in blog when it's planned.

3. Manual: the problem here is nearly same as with articles, but the solution is simpler, because amount of work here is smaller. So I hope I will be able to finish it soon.

4. Constant change of plans: there are actually several factors affecting on this:

  • We prefer to implement features that are requested by paid customers, and moreover, there are no good workarounds in cases they have. Certainly, this also depends on features (i.e. how they fit in our view & plans), but in general, this is the rule we follow pretty frequently, even if this breaks our plans. I'm not sure if this is good or bad - most likely, this is good. But announcing the plans with exact deadlines is bad in this case. On the other hand, I get "when?" question when I announce something (or answer "yes, it's a good idea" on some feature request) in almost 100% of cases, and it's clear, that I can't give trustworthy promises here.
  • Currently 3.5 full-time developers (incl. me) work on DO4. As you might notice, this is much less then what we had few month ago - there was a period when 8 developers were working on it. We're self-funded company, and our ability to dedicate developers to this project significantly depends on money it brings (unfortunately, currently we aren't happy with this - partially, because of this we decided to implement strict licensing), as well as people demand on other projects. And currently one of such projects really needs a lot of resources; thus DO4 development goes much slower - especially taking into account the fact people dedicated to it mainly work on licensing module on its server-side counterpart. So there are factors that are pretty difficult to control - e.g. in this case it was money-wise to move the people to another project. On the other hand, I believe even 4-person team will progress pretty fast here further. We needed 8 people while there were really dramatic changes and planty of work.
  • As I mentioned, I'm also paying role of sales person in this project. And I suspect I'd anyway promise more then we could do during some period of time in comparison to what project manager should say. And this should be fixed - we had a lot of internal discussions about this. Most likely, we'll do this by a radical way: there will be another PM and "plan announcer" further.

That's all the troughs I have for now. If you'd like to advise something, I'm fully open for any good ideas.


> I can imagine that “sacrificing” these requests for a greater good can be and should be justified.

We're actually doing this - i.e. we definitely won't implement any crazy idea that doesn't fit into our plans well. But if the person paid for something, and faces some issues there (not bugs, but issues), we're trying to resolve them ASAP, even although initially this wasn't planned.

> Maybe it’s an idea to start working with partners?

That's what we were re-thinking again as well. Hopefully, this idea will turn into an exact plan soon.


> Frankly speaking I thought you would not like this kind of posts being published here

It worth to be honest with the clients, so I'd never delete such a post, if you mean this :) Plus, the critics was absolutely constructive.

answered Jun 21 '10 at 21:04

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA