> This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
--B_3294094923_9815724
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
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=B9s
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=B9=
s
about the same distance as New York to LA or London to Istanbul. The
compan=
y
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
advance=
d
systems.
But then, do people want to build such sophisticated systems? Again, most
o=
f
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
script=
s
(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
deploye=
d
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
it=
s
focus onto producing do***entation 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.
H=
e
is an example of one relation****p:
condition =3D join =3D "contacts_personmember" LEFT OUTER JOIN
"contacts_person=
"
ON ("contacts_person"."primary" =3D "contacts_personmember"."fk_person")
LEFT
OUTER JOIN "contacts_addressdefault" ON ("contacts_person"."primary" =3D
"contacts_addressdefault"."fk_person" AND
"contacts_addressdefault"."primary" =3D
"contacts_personmember"."fk_addressdefault") LEFT OUTER JOIN
"contacts_levelstructure" ON ("contacts_levelstructure"."primary" =3D
"contacts_personmember"."fk_level") LEFT OUTER JOIN
"contacts_organization"
ON ("contacts_organization"."primary" =3D
"contacts_levelstructure"."fk_organization") LEFT OUTER JOIN
"contacts_branch" ON ("contacts_organization"."primary" =3D
"contacts_branch"."fk_organization" AND "contacts_branch"."primary" =3D
"contacts_levelstructure"."fk_branch") LEFT OUTER JOIN "contacts_client"
ON
("contacts_client"."primary" =3D "contacts_personmember"."fk_client") LEFT
OUTER JOIN "contacts_supplier" ON ("contacts_supplier"."primary" =3D
"contacts_personmember"."fk_supplier")
LEFT OUTER JOIN "contacts_staff" ON ("contacts_staff"."primary" =3D
"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=B9t 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
searc=
h
engine. It is really easy to do***ent 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 =AD too much to cover here.
To date, we have built commercial applications for four quite different
vertical markets; and now sup****t 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
almos=
t
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=B9d 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
--B_3294094923_9815724
Content-type: text/html; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Re: [pgsql-advocacy] Need for PostgreSQL demand?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>Hi!<BR>
<BR>
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.<BR>
<BR>
Here is my take on our first year in the open source domain as a wannabe
ki=
ller app:<BR>
<BR>
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&=
#8217;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
pa=
st 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.<BR>
<BR>
The system gets worked pretty hard over a basic 2 Mbps link between their
o=
ffices. I doubt that a competitor product could achieve the same outcome
wit=
hout spending a fortune on Citrix clients.<BR>
<BR>
But connectivity questions aside, is our application equal to an average
Fi=
lemaker or Access app? I would have to say no. Having PostgreSQL as the
unde=
rlying database allows our designers to build considerably more advanced
sys=
tems.<BR>
<BR>
But then, do people want to build such sophisticated systems? Again, most
o=
f the time, the answer is no, but the knowledge that systems can grow
withou=
t running out of steam should give IT managers confidence that they are
inve=
sting in a long-term solution.<BR>
<BR>
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
script=
s (if any). This level of complexity can easily be accomplished in
once:radi=
x. And with the GUI screen design tools and database editor (all in a web
br=
owser) and a basic understanding of application development and database
des=
ign, almost anyone can build equivalent applications that can be deployed
vi=
a browsers.<BR>
<BR>
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
b=
illion 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.<BR>
<BR>
Josh Berkus is right. A development and delivery environment that makes
Pos=
tgreSQL more accessible could have a dramatic impact on its popularity. We
h=
ave 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
m=
ake once:radix available to a wider community?<BR>
<BR>
But we are not waiting for things to happen. once:technologies has moved
it=
s focus onto producing do***entation that pitches the system to less
experie=
nced 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.<BR>
<BR>
Looking at our own application development, we try to keep things simple;
b=
ut we sometimes have to resort to some pretty ambitious database design.
He =
is an example of one relation****p:<BR>
<BR>
condition =3D join =3D "contacts_personmember" LEFT OUTER JOIN
"=
contacts_person" ON ("contacts_person"."primary"
=3D =
"contacts_personmember"."fk_person") LEFT OUTER JOIN
&qu=
ot;contacts_addressdefault" ON
("contacts_person"."prima=
ry" =3D "contacts_addressdefault"."fk_person" AND
&qu=
ot;contacts_addressdefault"."primary" =3D
"contacts_person=
member"."fk_addressdefault") LEFT OUTER JOIN
"contacts_l=
evelstructure" ON
("contacts_levelstructure"."primary&qu=
ot; =3D "contacts_personmember"."fk_level") LEFT OUTER
JOI=
N "contacts_organization" ON
("contacts_organization".&q=
uot;primary" =3D
"contacts_levelstructure"."fk_organizatio=
n") LEFT OUTER JOIN "contacts_branch" ON
("contacts_orga=
nization"."primary" =3D
"contacts_branch"."fk_or=
ganization" AND "contacts_branch"."primary" =3D
"=
;contacts_levelstructure"."fk_branch") LEFT OUTER JOIN
"=
contacts_client" ON ("contacts_client"."primary"
=3D =
"contacts_personmember"."fk_client") LEFT OUTER JOIN
&qu=
ot;contacts_supplier" ON
("contacts_supplier"."primary&q=
uot; =3D "contacts_personmember"."fk_supplier")<BR>
LEFT OUTER JOIN "contacts_staff" ON
("contacts_staff".&=
quot;primary" =3D
"contacts_personmember"."fk_staff")=
<BR>
<BR>
Sure, this example is not for the fainthearted but the great virtue of
choo=
sing PostgreSQL for once:radix is that when this level of database design
(o=
r more) is needed, we can deliver. Triggers and Functions, client and
server=
-side scripting, rapid application development, there is all this and a
whol=
e lot more in once:radix. I wonder how the competition would
han=
dle some of the tasks we ask PostgreSQL to perform!<BR>
<BR>
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
does=
n’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
ret=
urn an indexed list of the contents of that field in the database.<BR>
<BR>
We have a context-sensitive Help system with an inbuilt Apache Lucene
searc=
h engine. It is really easy to do***ent applications through that feature.
A=
nyone with a basic sense of organisation and the ability to produce simple
H=
TML can produce easy-to-access on-line help pages. And there is a lot, lot
m=
ore – too much to cover here.<BR>
<BR>
To date, we have built commercial applications for four quite different
ver=
tical markets; and now sup****t clients in Australia, North America, the
Cari=
bbean and Europe. We have enough practical experience to be confident that
o=
ur technology is fast, stable, secure and reliable.<BR>
<BR>
So what has happened to the open source project over the past year?<BR>
<BR>
Well there have been over 2000 downloads on SourceForge, representing
almos=
t 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
co=
me forward to help. To date, the response has been disappointing.<BR>
<BR>
We are a small business. If we’d had the resources of even a
mid-size=
d competitor, our position would be very different today and PostgreSQL
woul=
d benefit from it. We invested a couple of million dollars in product
develo=
pment. Like the marketing of PostgreSQL, now comes the hard part: Finding
di=
stribution channels, building market share, recruiting strategic partners,
e=
t al. This is always the most challenging phase in bringing new technology
t=
o market.<BR>
<BR>
We are still in there swinging!<BR>
<BR>
Regards<BR>
<BR>
Rob Napier<BR>
Managing Director<BR>
once:technologies pty ltd<BR>
</SPAN></FONT>
</BODY>
</HTML>
--B_3294094923_9815724--
|
