Re: Need for PostgreSQL demand?

Hi!

It seems that I dropped off the advocacy list last year and missed all the
activity six months ago when once:radix was part of your discussion about a
killer app.

Here is my take on our first year in the open source domain as a wannabe
killer app:

once:radix has been compared to FileMaker and Microsoft Access. That¹s not
surprising since we are serving similar end-user requirements. e.g. We have
a client in Western Australia where about 40 people connect to a local
server while another 15 people work out of their office in Melbourne. That¹s
about the same distance as New York to LA or London to Istanbul. The company
currently has about 6,000 jobs in their system, created over the past 10
months. They have more than 3000 client and supplier contact records,
project data, time sheets, requests for quotation, purchase orders,
invoices, and so on. And it links to a back-end accounting package.

The system gets worked pretty hard over a basic 2 Mbps link between their
offices. I doubt that a competitor product could achieve the same outcome
without spending a fortune on Citrix clients.

But connectivity questions aside, is our application equal to an average
Filemaker or Access app? I would have to say no. Having PostgreSQL as the
underlying database allows our designers to build considerably more advanced
systems.

But then, do people want to build such sophisticated systems? Again, most of
the time, the answer is no, but the knowledge that systems can grow without
running out of steam should give IT managers confidence that they are
investing in a long-term solution.

I should think that more than 80% of competitor applications use only a few
tables with very simple joins. At best, most would write only simple scripts
(if any). This level of complexity can easily be accomplished in once:radix.
And with the GUI screen design tools and database editor (all in a web
browser) and a basic understanding of application development and database
design, almost anyone can build equivalent applications that can be deployed
via browsers.

If serious database designers feel tempted to look down their noses at the
low end of the market, remember that Sun thought enough of MySQL to pull a
billion dollars out of petty cash to buy them. That would never have
happened if they had not first won the hearts and minds of low-end users.

Josh Berkus is right. A development and delivery environment that makes
PostgreSQL more accessible could have a dramatic impact on its popularity.
We have placed that technology in the public domain. We could achieve so
much if some of the PostgreSQL community took a more proactive role in
helping us make once:radix available to a wider community?

But we are not waiting for things to happen. once:technologies has moved its
focus onto producing documentation that pitches the system to less
experienced users, while also improving the information available to
developers at the top end of our target market. We hope that by addressing
both levels, we will begin to see a broader market acceptance.

Looking at our own application development, we try to keep things simple;
but we sometimes have to resort to some pretty ambitious database design. He
is an example of one relationship:

condition = join = "contacts_personmember" LEFT OUTER JOIN "contacts_person"
ON ("contacts_person"."primary" = "contacts_personmember"."fk_person") LEFT
OUTER JOIN "contacts_addressdefault" ON ("contacts_person"."primary" =
"contacts_addressdefault"."fk_person" AND
"contacts_addressdefault"."primary" =
"contacts_personmember"."fk_addressdefault") LEFT OUTER JOIN
"contacts_levelstructure" ON ("contacts_levelstructure"."primary" =
"contacts_personmember"."fk_level") LEFT OUTER JOIN "contacts_organization"
ON ("contacts_organization"."primary" =
"contacts_levelstructure"."fk_organization") LEFT OUTER JOIN
"contacts_branch" ON ("contacts_organization"."primary" =
"contacts_branch"."fk_organization" AND "contacts_branch"."primary" =
"contacts_levelstructure"."fk_branch") LEFT OUTER JOIN "contacts_client" ON
("contacts_client"."primary" = "contacts_personmember"."fk_client") LEFT
OUTER JOIN "contacts_supplier" ON ("contacts_supplier"."primary" =
"contacts_personmember"."fk_supplier")
LEFT OUTER JOIN "contacts_staff" ON ("contacts_staff"."primary" =
"contacts_personmember"."fk_staff")

Sure, this example is not for the fainthearted but the great virtue of
choosing PostgreSQL for once:radix is that when this level of database
design (or more) is needed, we can deliver. Triggers and Functions, client
and server-side scripting, rapid application development, there is all this
and a whole lot more in once:radix. I wonder how the competition would
handle some of the tasks we ask PostgreSQL to perform!

Our interface is more like a conventional client-server application than a
web app. And that interface is part of the environment. For example, it
doesn¹t take special programming to create search, browse and edit modes.
Also, searching in most fields take no more effort than a mouse click to
return an indexed list of the contents of that field in the database.

We have a context-sensitive Help system with an inbuilt Apache Lucene search
engine. It is really easy to document applications through that feature.
Anyone with a basic sense of organisation and the ability to produce simple
HTML can produce easy-to-access on-line help pages. And there is a lot, lot
more ­ too much to cover here.

To date, we have built commercial applications for four quite different
vertical markets; and now support clients in Australia, North America, the
Caribbean and Europe. We have enough practical experience to be confident
that our technology is fast, stable, secure and reliable.

So what has happened to the open source project over the past year?

Well there have been over 2000 downloads on SourceForge, representing almost
70 GB of data transfer. Not a huge number when measured against many open
source projects, but still quite credible. We had hoped that people would
come forward to help. To date, the response has been disappointing.

We are a small business. If we¹d had the resources of even a mid-sized
competitor, our position would be very different today and PostgreSQL would
benefit from it. We invested a couple of million dollars in product
development. Like the marketing of PostgreSQL, now comes the hard part:
Finding distribution channels, building market share, recruiting strategic
partners, et al. This is always the most challenging phase in bringing new
technology to market.

We are still in there swinging!

Regards

Rob Napier
Managing Director
once:technologies pty ltd