A call for review

What I am about to put in this message will not be well received I fear, 
and some will undoubtably say that it is negative and mean spirited. To 
those that feel so, I assure you it is not my goal.

A few months ago I started seriously investigating the use of OOBase as 
a development tool, not for personal use but to deliver applications to 
clients. It has become clear that the tool as it has been developed 
falls far short of being suitable for such purposes.

I do not mean for this message to be taken as an attack on any one in 
the OpenOffice development group, but I also do not intend to mince my 
words. Before proceeding just one small bit of background. I am not a 
proponent of OpenOffice, it is a tool nothing more. I would like to see 
it have success for a number of reasons, one would be purely 
self-serving. I could use it as a means to generate income. For this 
purpose it is far from the only choice. The other reason is broader, I 
believe in the free market system and for that to work there must be 
competition. As I see it OpenOffice is the best postitioned office suite 
out there to give Microsoft a serious run for its money and if that 
could happen everyone would be better off. So what I have to say here is 
intended to help further that goal, please take it in that sense.

Now for my main points. I fail to see how the current implementation of 
Base meets any particular users needs. It seems to be too hobbled, by 
design, for serious consideration as a development platform. It also 
seems to be too lacking in ease of use features to make it useful for 
the casual user. What do I mean by this?

In the case of data enty forms management you have basically taken the 
existing Writer document as container for databae form controls, 
functionality, removed some of that functionality, or at least made it 
more difficult to get to, and moved the physical storage of the file 
into a databae file. What real benefit did this bring to either the 
casual user, or the databae developer. I will come back to this point 
later. Before I leave it however, I suggest you take a look at the 
number of people that have truly struggled with the simple task of 
opening a form from within a macro. It is far from just a matter of lack 
of documentation. A person has to understand not just the difference 
between a forms definition object and its instantiated object, but must 
have a good grasp of scoping issues within the Basic interpreter. 
Granted you can always just double click a form name from the GUI, but 
even realativly novice users expected to find the ability to designate a 
default form that would open when the database file is opened. A process 
that is not even easily performed via code. Because of this the users 
are already moving away from embedded forms and sticking with stand 
alone writer documents.

Second is the issue of a report writer for Base. I will say this as 
simply and bluntly as I can. The wizard that is supplied is simply a 
poor replacement for a report writer. In reality this wizard supports 
one report layout, yes it can use a number of different character styles 
and you can choose between grahpics of coins, or litle stick men, but 
the basic layout of the report is the same. Beyond producing shopping 
lists I do not see how this was expected to fulfill the needs of a 
serious report writing tool. Granted in the case of external data 
sources one could use different report writers, but in the case of the 
embedded database, as of this moment, I do not believe there is any 
other choice beyond the report wizard.

Third, script management. Given that the databse file does not support 
the attached basic library stucture that the other doucment types in OO 
do, and that attaching any macro code to form documents causes a 
conflict with the macro security module one is faced with always putting 
code into outside libraries. Another hurdle for the novice user, not 
much of a problem for the databse developer I would admit. However, 
there is another issue here. One can, as far as I can tell, only address 
forms from within scripts. Try to work on the rowset that is represented 
by opening a table directly and there seems no way to do so. This makes 
creating macros that would be truly useflul as a means of enforcing 
business logic rules on the data virtually impossible. Add to this the 
selection of a database engine that only supports stored procedures via 
creation of Java classes and you have effectively removed a sizeable 
number potential in-house developers.

Then there is the issue of stability.

My understanding is that release 1.9.130 is, or is very close too, the 
first release candidate for OpenOffice verison 2.0. If this is the case 
then there seems to be a serious amount of work left to do. Just today 
it became clear to me that the very first requirement of a database 
management system, as it pertains to the embedded database engine, is 
not being met. You must not, if possible, lose the data! I would refer 
you to new issue #54609 
<http://qa.openoffice.org/issues/show_bug.cgi?id=54609>, and my obsurd 
test that I recount at 
http://www.oooforum.org/forum/viewtopic.phtml?t=24043 . I call it 
absurd, because it should be clear that one record would have been 
enough, but the point is made quite concrete with a million.

I want to put forward the proposition that the problem with Base lies 
not so much in the current code, but rather in the attitudes that went 
into developing the module itself. For this I point to a few items.

First - From the database_application specification. Section 2 
Motivation. The first paragraph is

"One of the most annoying things is that people ask on the 
OpenOffice.org lists, "Does OpenOffice.org also support databases?". 
This has been the case since the first release. The problem is that the 
database part of OpenOffice.org was not that intuitive to find and the 
approach of data sources was hard to understand. Another point is that 
the current implementation is too development specific resulting in the 
normal user not recognizing the intention of the links in a data source. 
This has to be changed."

Second  - From the Embedded Database specification. Section 1 
Motivation. The first paragraph is

"The difference of database data and other database aspects like 
queries, forms, or reports is for the user often hard to understand that 
they are saved in different locations. If the database itself is not 
included in the file, the database application creates, it is always 
possible that the user forgets to copy the database as well, when he 
wants to e.g. send it via e-mail. Therefore the database application has 
to write the information about queries, forms, and reports but also the 
data if the user selects the embedded database as well."

And Section 2
"An user scenario could be for example sharing database files, the 
description above is more a bug description."

Then there is this from the a posting on the dba features mailing list, 
dated yesterday.

"Technically, this new behaviour is an enhancement, since it introduces
new functionality for this particular database type. To the user, it's
the fix for a bug (which in fact has been reported several times in
the Beta test), since s/he expects from OOo's pet database HSQLDB to
offer the most basic "rapid database design" functionality."

Am I reading these correctly, the main motivation was to get the users 
that where not smart enough too understand how a database server worked 
to stop annoying the support staff. Or is it that one should fix a bug 
that made it possible to forget to copy some files. Should I take it 
that this is not really a serious tool, the embedded database manger, 
but a 'pet'.

IMO there is a trend here. There is a belief that what you had before 
was sufficient and what you are creating now is, well, not really worth 
the effort.

It is with all earnestness that I ask you to think about this. Like it 
or not when you announced the inclusion of a database module in 
OpenOffice you created an expectation amongs new possible users. On this 
point I believe there may exist the largest problem of all. Who is the 
target user of a databae module. I don't believe it is the user that 
will put data into a data entry form, nor the user that will run the 
reports. Although, these will be the greatest numbers of persons. A 
database module will be fundamentaly different then say a word 
processer, where the focus of the application is the document and the 
primary user the person creating the document. IMO the primary user of 
the module will be in-house and third party database application 
developers, for the database is used to implement processes within an 
organization. Up till now, I believe, the focus of the datasource 
controls within OO have been to feed data into documents. Not used as a 
basis to build data validation and process mangement applications. But 
these are precisely the uses your competitors database is used for. 
Again look at the OOOForm postings, for every one person that is talking 
about a very limited, trivial database application, there is a good 
number talking about small office automation tasks. I personally have a 
hald dozen people on the board that have spoken with me in depth, off 
line, some even supplying there database files and requirments so that I 
might help them. These have been people expecting to find a database 
system capable of automating work processes within organizations ranging 
from 3 users to 9 users. OOBase as it is conceived is not capable of 
this without using an third party database engine, which I contend 
defeats the purpose of having it as a stand alone module in the first place.

In closing let me say this. There will be a large number of people that 
will come and take a serious look at OO now, because of the Base module. 
Many if not most will be comparing it to MS Access, with this being the 
measuring stick I am afraid that  OO.o will not get a long review.

I urge you to take the time to sit down, look at what you intend Base to 
be and who it's intended audiance is and then make these known to the 
public. For right now, what is being expected and what is being 
delivered are far from the same.

Sincerely

Andrew Jensen