How about setting up yet another company? - Mailing list pgsql-jobs

Dear PostgreSQL lovers,

There have been discussions in advocacy list regarding ways to make
PostgreSQL ubiquitous and to expand market share. IMHO it can be
considered being more aggressive to help this community by our own
efforts than to sit and wait big commercial entities carrying suitcase
full of cash starting to sponsor this community or PostgreSQL related
projects. I, a long term PostgreSQL diehard, am talking about setting up
a company being capabable of leading its followers from everywhere to
charge against the competitors _now_ and seize the hight-end market share
_today_.

I have an ERP system. It exclusively uses PostgreSQL as its DBMS. It is
developed in Borland C++Builder (BCB). It is a multilingual multiple-tier
thin client ERP system especially suits manufacturing and distribution
industries. All modules tightly integrate with accounting module. The
application server and the client program unfortunately requires Winodowz
at this moment. Some propaganda can be found in http://www.ress.tk

The procedure for this proposal begins by setting up a "headquarters".
Once this headquarters exists, it will immediately invite everyone on the
earth to setup "branch offices or subsidiaries" at any spot of the earth
surface. My idea is selling this ERP and starting to generate capital
through branch offices.

Now questions start to arise and my humble immature answers follow too
:-)

(Q1) What are the details for this headquarters?
(A1)
(1) I am not picky about the location for this headquarters. I won't
object if someone suggests Tokelau.
(2) The following categories of people or organizations appear to be
ideal candidates for "the board of directors" to me:
- PostgreSQL developers (only if they are interested in this, of course)
- those who can generate remarkable number of customers
- those who have substantial amount of capital to invest on marketing
activities
- those who are able to conduct ongoing product improvement
- those who are able to provide after sale services
- those who possess good business know how (such as MRP theories,
accounting, costing) or social skills, and are ready to help branch
offices deploying ERP to customers
- those who are good in running companies
- (and please don't forget) myself

(3) Some major responsibilities for the headquarters are:
- marketing (primarily by means of web and media)
- conducting ongoing software and documentation enhancement
- providing technical support to branch offices especially when the
latter are deploying ERP to customer sites
- providing after sale services (primarily by means of web)
- pointing customers to branch offices for new business opportunities

Once the headquarters is there, I will immediately transfer the ownership
of this ERP including the source code to it.

It might be worthy notice that I am not asking for big share from this
headquarters because I can still run my own branch office as everyone
else does. As to the reasonable percentages of share for each of above
"board of directors", someone in this list are probably willing to help
answering.

(Q2) What are the details regarding the branch offices?
(A2)
(1) Regarding the condidates, I would recommend anyone be invited.
Anyone, indeed! Even a single person is eligible too. However, one
condition should be applied to the startup - the headquarters gains a
predetermined share of every sales income made by the branch office. I
don't have good answer to the reasonable percentages between the
headquarters and branch offices. Perhaps the board of directors will come
out some answers for it.

(2) Some major responsibilities for branch offices are:
- procuring contracts
- deploying software to customers
- collecting income and feeding back a portion of it to headquarters

(Q3) Why sell ERP instead of other software or services?
(A3)
(1) Because ERP is the best object with which PostgreSQL is able to
demonstrate to the world its technical superiority to its competitors. We
all know too well that too many DBA's believe that m*SQL is good enough
for their applications. Also there are not just a few people who think
that PostgreSQL is not good enough to replace Or*cle. I believe in order
to remove such barriers, holding a powerful, stable, fast running, and
widely deployed ERP in our hands as our weapon, we can easily prove such
thoughts being ultimately wrong. This will be especially true when we
acquire well known big ERP customers. Note that we can still continue to
penetrate the DBMS market through the sales of our ERP even we fail to
convince some or most of stubborn people the bloody truth.

(2) I won't surprise at all if someone tells me now that S*P is porting
its ERP to m*SQL. This is indeed a serious issue to PostgreSQL community
if this assumption is true! I would not expect PostgreSQL to surpass
m*SQL in low-end market in any foreseeable future. Worse is that the
high-end market will also belong to m*SQL when S*P completes its port
before PostgreSQL swallows most part of the pie in high-end market.

Optimists may argue that S*P can't conduct the port due to m*SQL's lack
of features/capabilities essential to ERP development. While agreeing
with such statement, I won't think that they will never be able to change
this fact. In fact, they are catching up with us - either slowly or
quickly. I won't be surprised, either, if someday someone tells me that
S*P finishes the port in 2 weeks right after m*SQL starts to support
subquery, RI, stored procedures, and triggers.

It is also noticeable that most people prefer to stick to whatever DBMS
they are using now when they need advanced features from DBMS's in order
to enhance their applications. In other words, most of the current m*SQL
users will simply upgrade to newer versions of m*SQL and start to
implement more complex applications like ERP. I don't expect the existing
m*SQL users to turn to PostgreSQL only because they need the advanced
features being already available in PostgreSQL but unavailable in m*SQL.

The point I have been trying to express is that we must open a new
battlefield now. I won't spend any minute waving hands to existing m*SQL
users saying "Hey! We have all you need which can not be found in m*SQL!"
Why don't I? Because I have never seen any local banks, insurance
companies, or big hospitals planning to migrate their expensive Cobol
applications in mainframe to cheaper and more productive RDBMS driven
applications.

The moral of these paragraphs: What will be PostgreSQL's next possible
niche market once it loses the market shares in both the low-end and
high-end applications?

(3) ERP can sometimes generate huge amount of cash. Taking S*P as an
example, it is not rare that it dare to ask its customers to pay $10
million+ for some CD's and pieces of paper which compose so called "ERP"
when it knows that customers are rich enough and are unable to refuse. I
think capital is also a good stuff to PostgreSQL community.

(Q4) Why choose my ERP rather than others' stuff?
(A4)
(1) It is ready - you ignite it and it fires. Everyone can sell it to
customers right now. We can't afford to waiting, can we?
(2) It is able to handle nearly all complex business types for
manufacturers.
(3) It is exclusively PostgreSQL driven.
(4) The business logic is 100% implemented by tables, triggers, RI,
PLPGSQL or SQL functions. Thus it runs fast (if one believes PostgreSQL
runs fast) and it's easy to be understood by programmers/DBA's.
(5) Since all its business logic is implemented in PostgreSQL and most,
if not all, tables are in 4th normal form, the BCB code primarily manages
only user interfaces and multiple tier computing. That is said it is not
too hard to rewrite it in Java, .net, palm or anything else if anyone is
willing to.
(6) It is simple in users' points of view. It supports on-line help for
nearly all forms and columns. This system contains only 77 forms at this
moment.

Without evidence, I believe m*SQL now gains 0% of ERP market share while
PostgreSQL has already acquired some. We have fair chance to beat m*SQL,
S*P, and Or*cle in this field. How about taking some actions now before
it's too late again?

The aforementioned proposal/strategies are primitive. Comments are
welcome.

Best wishes,

CN

--
http://www.fastmail.fm - Accessible with your email software
                          or over the web