[Chandler-dev] What is next for Chandler desktop?

[Phillip J. Eby]

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.)