A tale of a Berkeley DB project: Success and future developements

Question

The site http://www.electre.com is an on-line catalog of all published French books (close to 1 million of them), from the 1970’s to today, with pricing and availability information for professional users.
The entire book database and search engine was developed with Berkeley DB. The site runs relatively problem free, and owes much to the stability and quality of the Berkeley DB source code. Moreover, the software is sold as an intranet version and runs on remote configurations that are out of our direct control. And yet, we don’t get much problem reports from these remote sites.
Development started in 2002. Using Berkeley DB was my decision. It was, with hindsight, a very good decision, but it would be hypocritical to affirm I knew all along it would work out so well. It was partly a gamble, and partly a calculated risk. I am not ashamed to confess that when I finally made the decision to go with Berkeley DB, there were some key areas in the technical design I had no clue how to tackle. Needless to say, any flaws that remain in this area are due to lack of knowledge and lack of foresight on my part, not because of some flaw in Berkeley DB.
What convinced me 4 years ago to “go for it” was Sleepycat’s no-nonsense approach to support from guys like Michael Cahill, Keith Bostic, John Merrells, Dave Seglau, Michael Ubell, Liz Pennel and others. Support was sending a message to [email protected]. Replies were never more than a couple of days away (including time zone differences). There was always something comforting when you read a reply from someone who says he “owns your problem” (especially when you also saw that someone’s name in the source code <g>). The majority of support questions were asked during evaluation and product development, before even a single dime was paid to Sleepycat. (Now that we sell the product as a closed source Intranet solution, we gladly pay the required license fees, of course). The fact that the project development went so well was in no small part thanks to the competence and reliability of the people I communicated with. I never expressed my thanks, so now is as good a time as any to do so. Thanks, guys (and gals).
When Sleepycat was bought by Oracle, it was rumored that the goal was ultimately “to kill the product”. I thought that was ridiculous and an exaggeration by some paranoid people (especially from the MySQL-camp). I understand that Oracle is a big company, and that things are done differently now. Besides, how do you “kill” a product? I didn’t know until I hit my first support question “post-Sleepycat”. So now I do: you kill a product not directly, but, but by a process of what I call “incremental discouragement”. It’s a subtle, 3-pronged approach:
1)     Erect bureaucratic barriers between competent people and your customers. No more [email protected], but a slow and unwieldy web site and a support procedure hiding behind numbers and requiring a 2 hour training session. I’m not sure how I’m going to motivate to management a 2 hour training session for a product we’ve been using for the past 4 years, and which I now master sufficiently to reduce my support requests to about 3 a year, and for which the only difference is a change of company name. There’s a “free” forum, but the primary motivation for it seems to be to allow users to support themselves. Yes, questions are answered on the forum… but compared to the level of support I’ve been accustomed to from the same people in the past, I can’t help noticing something has changed… and not for the better. Some questions aren’t even acknowledged, though they are read over 300 times.
2)     Add useless levels of indirection: when we sell an intranet, we asked Sleepycat to mail us an invoice, which we got within the week. Now we ask Oracle the same thing: the last time we did this was on November 27 of last year, and we still waiting for someone from “the Belgian office” to contact us. The only reply we got was from someone telling us our request would be passed on: a level of indirection not exactly adding value.
3)     Increase useless Information Noise: www.sleepycat.com was all about Berkeley DB and related products. Look at any page on the www.oracle.com site supposedly about Berkely DB and count the number of items and links pointing to products that have nothing to do with Berkeley DB. It’s like that famous analogy: you’re only interested in a banana, and you must take the whole gorilla.
Berkeley DB is the fire behind the electre.com site. Our customers are satisfied, so this is not going to change for this version. But this developer is now convinced to view Berkeley DB as a medium to long-term liability. The fire will be kept alive for the remainder of this electre.com version, but for future versions and other similar projects, other solutions will have to be found. These other solutions will involve a similar gamble as the one I made a few years ago with Berkeley DB. My only hope is to meet similar competence, friendliness and professionalism, but without the overhead and bureaucracy of an organization for which the product is not even part of the core business.

Answer 1

Vincent,
I hear the frustration and concern in your post. I'd like to assure you that we're still here doing what we've done in the past and that your business is valuable to us, don't give up yet! :)
Moving from a company of 30 people to a company of >50,000 people has been an interesting transition for us as well. I have to say that honestly, things are pretty good here inside the realm of Oracle. Of course, some things were bound to change. Oracle has processes in place to acquire and grow companies and that is their intended goal with Sleepycat's Berkeley DB products. As such, some customer facing processes have changed and our home on the internet has been incorporated into the oracle.com site. The interesting thing to me is that even within Oracle's infrastructure you, the customer, are not really much further away from our engineers and support staff than before. Your suggestions, concerns, questions and bugs go directly to us via the same people pre-acquisition for the most part, although that staff is growing. With these OTN forums you have a way to speak directly to most of the Sleepycat staff, 99% of whom are still here at Oracle nearly one year post acquisition. So, I'd argue that we've done a great job of keeping that small company feeling in one of the largest software providers around.
Our web content is 80% identical to that which was on the sleepycat.com sites. Bookmarking one or two locations within Oracle and OTN will get you straight to that information. Sure, there are other product references floating around on the same page and we hope that over time Berkeley DB products and other Oracle products complement each other when used in combination. In general, I believe that most of the web experience is identical with different style sheets and a few extra links.
Support for eval customers continues to be something we provide free of charge via these forums and in private email conversations with our staff. This is unchanged. Ownership of customer issues is much the same as well and we do still use '[email protected]' for tracking issues once opened. We agree that '[email protected]' method of communication was simple and highly effective for us and our customers. We are working with Oracle's support infrastructure to consider adopting similar methods. This is another reason Oracle purchased Sleepycat, to learn from our efficient effective operational model. This is something that is ongoing, in the mean time we still track issues behind the scenes the same way as before with the added information provided by TARs so that we fit into the overall Oracle support infrastructure.
The rumors of our early demise are highly exaggerated. Berkeley DB products are alive and well in Oracle. Just look at the releases we've made in the past 12 months.
As for our three pronged attack. ;-)
1. The distance between first contact with support and helpful information has, in some ways, increased. This is due to the Oracle infrastructure for support that manages all Oracle products. The forums are the replacement for the discussion email lists we managed at sleepycat.com. We're managing a much larger amount of traffic than in the past and most of it is done with the same Berkeley DB engineering team you've come to know and love. Maybe we need to make it more obvious when we answer a question by having a signature indicating who we are, sometimes that's not obvious. As to the particular question you posed, I don't know what happened but the same thing can happen on an email list. My apologies for the lack of a response.
2. Oracle has a huge sales force worldwide. We're only beginning to fully function within this new infrastructure. Sorry we dropped the ball on your sales inquiry, rest assured that we're interested in all commercial deals. Once connected into the Belgium office you'll have a direct relationship, as before, with a sales rep for your use of Berkeley DB.
3. I've already talked about this. Oracle has many products, we're just one of those. We have to fit within the overall site structure. For the most part I'd give us an A- or B+ for transitioning our sleepycat.com information into oracle.com and OTN.com. If you have suggestions as to how we might improve that, drop me a line I'm all ears.
In general I'd like to believe that you and other developers like you will find that our place in Oracle doesn't prevent you from choosing Berkeley DB. Certainly it is a bigger company with some additional process overhead, but hopefully not so much that it prevents you from remaining a loyal customer and someone who would recommend us to others.
regards,
-greg
Gregory Burd [email protected]
Product Manager, Berkeley DB/JE/XML Oracle Corporation