Skip site navigation (1) Skip section navigation (2)

Re: Usability, MySQL,, gborg, contrib, etc.

From: pgsql(at)mohawksoft(dot)com
To: josh(at)agliodbs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Usability, MySQL,, gborg, contrib, etc.
Date: 2004-04-26 19:41:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Hey,
> First of all, who is this?   I don't recognize the e-mail, and you haven't
> been signing any of your posts.

I've been posting on hackers on and off for a few years. My name is Mark.
>> true, others, however, are very welcoming to direction.
> AFAIK, this includes none of our major code contributors.   So all you're
> really talking about is manipulating the TODO list.  You can't tell
> programmers what to code unless you're paying them.

Yes and no. People can and do what's needed when it is clearly
articulated. What is lacking is a clear direction WRT marketing.

>> It depends in the
>> individual. Lastly, Bruce, Tom, Peter, and others are very didicated to
>> PostgreSQL. If a real case can be made for a feature, I'm sure they are
>> reasonable enough to see that and grudgingly implement it. Someone,
>> however, has to keep an eye on that ball.
> Yes, but they don't need  a title to do so.   Nor is there any reason for
> this
> to be one person.  In fact, you've just described one of the reason for
> the
> Core's existance -- and even the Core defers to the consensus of decision
> on
> this forum about which features to implement and how.

I think I am talking about something different. In a company, the core
team would be the CTO. I think some entity, one or more people, needs to
define the product. Typically this is marketing and product management.

> Now, if you're arguing that we could use a more cohesive, readable
> roadmap?
> Sure!   Want to prepare one?  I can even help you find out what's under
> development and what's not likely any time soon.

Absolutely, but it would be meaningless if no body listens.

>> Linux has Linus, he has a very good eye in the market forces.
> Uh-huh.   So?   That still doesn't make him a "product manager".

Maybe I've overstated my case, by management I mean the small 'm' not the
big 'M'

>> OpenOffice is very much
>> managed by Sun.
> I used to be a Project Lead for

Very cool. It is a great project/product.

> I think the amount of
> consensus and compromise, and the extent to which the Community Council
> and
> the Project Leads govern the project, would surprise you.

No it wouldn't.

> Overall, I've not seen you present any coherent arguments as to:
> 1) why we need a new person with a title for marketing stuff;

The why is that there is no real entity doing so.

> 2) what this person would be doing that's not already covered by existing
> groups;

All the groups, with the exception of advocacy, are "here's what we are
building" and "here's a bug" groups. There is planning on hackers, but it
is almost purely technical. Marketing features do no often get a
reasonable hearing.

> 3) how this person would be able to accomplish their "job";
I think that a talented manager could make the case for certain features.

> 4) who this person would be.
We recrute like a company does.

> As far as I'm concerned, we need use titles here only if it lends the
> entitled
> some kind of authority with the outside world that helps them on their
> volunteer projects (Robert Bernier, "Business Intelligence Analyst", is a
> good example of a good use of titles -- that one convinces companies that
> he
> approaches about case studies that he's for real).   Titles are not at all
> useful *inside* the community, we don't need them.

I'm not trying to change the dynamic significantly, but I think, again if
increasing usership is important, that some market driven lessons need to
be  learned.

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2004-04-26 19:46:54
Subject: Re: Usability, MySQL,, gborg, contrib, etc.
Previous:From: Bruce MomjianDate: 2004-04-26 19:19:21
Subject: Re: signal 11 on AIX: 7.4.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group