At 01:33 PM 9/13/2007 -0700, Jeffrey Harris wrote:
Hi Phillip,
I can definitely understand your frustration that people aren't
responding to your questions and thoughts about funding. I think
(though I'm by no means sure) this is because we've been encouraged to
discuss funding strategy in our internal strategy list, instead of on
this public list.
It may well be that conversations about funding and architecture are
inseparable, in which case we're in a bit of a quandary.
Personally, I'd be fine to discuss potential revenue in public, but I
don't have a handle on what we'd lose if we started discussing funding
on public lists.
I'd be sad if our architecture discussions were pushed into private lists.
My point isn't that developers need to be procuring revenue
themselves, but rather that project, organization, and product must
all be designed in terms of some goal. (Because "writing code
doesn't make money". Design decisions and project decisions have to
be directed towards the goal, in order for writing code to *support*
making money.)
If work is taking place on those models on another list, the output
that's desired from that process are things like:
* who are the users whose needs should be met
* what features are free draws and which are used to motivate payments
* how far in advance of funding cut-off must the features be delivered by
and so on, which I would think can all be discussed without revealing
any confidential details. (E.g. "yes, we're working on grant or
merger possibilities, and here are the things most important to our
current prospects", or "yes, we are pursuing a service-oriented
revenue model where the client's job is to entice/encourage people to
use the hosted service.")
But without this kind of information, project management and software
design are simply flying blind. Merely saying we're going to produce
some set of features by some deadline for some set of users isn't a
sufficient specification to allow for success... unless it just
happens by accident. (Which is unlikely, since the absence of the
information means people are much more likely to disagree about
what's "best" -- another factor that affects our delivery capabilities.)
Whether it's grant-driven, investor-driven, advertiser-driven, or
user-purchased product/service driven, there is in all cases a
*customer* -- who may or may not be the same as the "user".
So who is our customer, and what do they need in order to give us
money? That is the desired practical response to the questions I'm asking.
(Even if the customer is someone like "AdSense advertisers", this is
still not necessarily enough to turn mere quantity of "users" into
revenue, since not all users are of equal value to advertisers.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
