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

[Phillip J. Eby]

At 09:03 AM 9/13/2007 -0700, Philippe Bossut wrote:
>  What we need to prove is that there's a demand for that set of 
> qualities in a PIM. That I think brings us back to "getting users" first.

I think there's a far more profound issue that is getting near-zero 
discussion here, although I've raised the question more than once.

At my first software development job, 23 years ago, the president of 
the company had a mantra that he constantly repeated to new 
developers: "Writing code doesn't make money."

I would note that in the open-source case, this principle has a 
corollary: "Getting users doesn't make money, either".

Which means that development stops in 15.5 months, unless one of two 
things happens:

1. There is actual revenue or contributions coming in before that 
date (sufficient to make the subsequent payroll), or

2. There are volunteers taking over development before that date (so 
that there is staff still in existence to answer questions and get 
people involved).

So it is inaccurate to think that we actually have 15.5 months of 
*development* time, during which we will be conducting "business as 
usual".  It is reasonable to expect, for example, that staffing may 
decrease as the deadline approaches, since some people will want/need 
to find new positions if there is no plausible path to continued funding.

So if we succeed only in *shipping* a shiny new Chandler 1.0 in the 
next 15.5 months, we will have failed, not succeeded.  There will be 
nobody there to support or maintain it, except for the part-time 
volunteer efforts of any former OSAF staff who care to do it.

We need to allow enough time for a transitional period that's focused 
either on revenue development or the transition to an all-volunteer 
team, or both...  *and* we need to allow for the historical rate of 
release slippage that has occurred for prior releases, in *addition* 
to that (unless we are going to use a different approach to the 
release process).

I don't know what the precise data is on that slippage, how it works 
in percentage or absolute terms historically, and whether it's been 
growing or not.  However, it's important to realize that we can't 
afford to act as if it doesn't exist.  Historically, OSAF development 
practices are not sufficiently risk-driven to set reliable target 
dates, in that many of the riskiest tasks are often left to later in 
the development cycle, and the single biggest cause of variation in 
shipping time (bug fixing) is left to the *very* end of the process, 
every time.

This is maddening to me in part because in my 24 years as a 
professional software developer, I have *never* been a part of a 
project that slips as much as Chandler does -- and it's entirely due 
to *correctable* organization and process issues.  The outputs of a 
software development process are not random; they are driven by 
systemic causes and effects.

(This is *not* an issue of the people involved -- everybody is doing 
the best they can.  It is quite simply OSAF's organizational design 
and project design that are at fault.  The best efforts of every 
individual are not sufficient to alter the *process* within which 
their efforts are embedded.)

Now, I've mentioned all these things before.  And I've asked for 
anybody to correct me if any part of this is in error.  Do we 
actually have some sort of revenue model?  Some foundation we're 
working with for a grant (those things usually have a lot of lead 
time, don't they)?  Do we have anybody actually *working* on either one?

Am I wrong about the deadline?  Wrong about the transition needs?  Is 
there some magical process I'm not aware of that turns users into 
money without any planning or work on our part?  Because if not, then 
the entire frame around this discussion is broken.  A significant 
part of what's being written in this thread by most people seems to 
have an implicit assumption that "business as usual" will somehow 
magically result in paychecks continuing to get handed out.

And that assumption appears to me to be seriously at odds with the 
reality of the situation.

Which is why I believe the only question worth asking is, "what do we 
want to have at the end of the current funding?"

If what people want is to still have jobs working on Chandler, then 
the focus of the discussion needs to NOT be on "users" as such, but 
on how we'll be converting those users into *cold hard cash* to pay 
for those jobs.

Now, my original framing of the issue was based on the assumption 
that we will *not* have those jobs as of December 31, 2008 -- or *sooner*.

Hence, my questions and statements have focused on what we want to 
have happens *after* we are no longer being paid to work on Chandler: 
what software we want to have delivered, and whether we care about it 
continuing to be developed and maintained.

And it seems that the general consensus is that people don't want to 
think of it that way, and would prefer to think in terms of still having jobs.

Great!  But in that case, the only thing we should be working on is a 
*revenue* model.

And confusing "users" with "revenue" is a mistake.  (As is thinking 
that "having lots of users" is the same as "attracting lots of volunteers".)

Having users is a necessary condition for these things, true.

But it is far from being a *sufficient* condition.

I'm really curious to see what the response to this will be, because 
the other times I have asked people specifically about where the 
revenue is supposed to come from, my messages were replied to...  but 
those specific questions were not answered.

I would be happy to be wrong.  But so far, I haven't heard anything 
that even *addresses* these questions, let alone disputing my 
hypothetical answers.