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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
