[Asterisk-Dev] Asterisk Maintenance and Development

[Jim Van Meggelen]

Howard White wrote:
> On Mon, 2005-01-03 at 12:27, Jim Van Meggelen wrote:
> 
> <snip>
> 
>>> The growth of Asterisk (the program) and Asterisk (the
>>> community) demands that the keepers of the keys (Mark;
>>> Digium) institute proper, formal and documented Product
>>> (Program) Life Cycle techniques.  We all wish for Asterisk (the
>>> program) to be accepted by a wider audience which may only be
>>> accomplished by having a clear path of where Asterisk is going (and
>>> by when).
>> 
>> This is a laudible goal. If I am correct in assuming that you posses
>> the required skills, am I also correct in accepting this as your
>> offer to join the maintenace team? We could use that kind of help,
>> no doubt about it.
> 
> VCCH, Inc. _is_ contributing (and reselling :))  Yes, I am
> looking for a role in which to contribute.  COBOL and FORTRAN
> are not much in demand...

But possibly project management skills are. Besides, if you know one
programming language, you can learn another.

>>> Yes, I know that Asterisk is an open source project that depends on
>>> the generous support of uncompensated programmers in their spare
>>> time.
>> 
>> Asterisk has now matured to the point where more than just developers
>> and documenters are needed. If you have project management
>> experience, then your skills are needed as well.
> 
> Mark Spencer is in direct control of what I describe and
> shall have to delegate in order for anyone to contribute.

Yes and no. The copyright on Asterisk belongs to him, but to say that we
cannot do anything without his direction is simply not true. There are
many things that exist in the Asterisk community that were not started
nor are controlled by Mark. I know for a fact that many of these
initiatives delight him (and take a burden off his shoulders); perhaps
some annoy him as well. Regardless, they were started by people who
perceived a need, and took the initiative to address them.

>>> Please look at the wall in front of us and let us collectively
>>> figure out where and how to cut a door before we slam headfirst.
>> 
>> Excellent point. Are you volunteering to lead the project management
>> team that will be responsible for meeting milestones?
> 
> see above

See below.

>>> How many sub dot releases are we planning in 2005?  What are the key
>>> milestones to be accomplished for each sub dot?  What are the
>>> milestones to be provided in two dot?  And when is two dot?
>> 
>> Don't passively ask: actively propose something!
> 
> I am, stay tuned.

Don't be so obtuse. Describing your contributions may inspire others to
contribute (or offer you their help).

>>> Asterisk (led firmly by Mark and Digium) has seen the great
>>> accomplishment of one dot zero.  For releases to be taken serioulsy,
>>> we must now have a Product Life Cycle - from Mark and Digium.
>> 
>> Frankly, Mark and Digium contribute enough already. What we really
>> need is more people actually contributing, and less folks actually
>> just talking about what is wrong.
>> 
>> Regards,
>> 
>> Jim Van Meggelen.
> 
> Jim, these last few thoughts of yours are where we disagree.
> Mark is "the single point of failure" that is in charge of
> Asterisk.  What I propose by introducing established Product
> Life Cycle tools is a means by which Mark may chart the
> future course of Asterisk development and then delegate the
> management thereof to other Digium staff or Asterisk
> volunteers.  Asterisk is now larger than what Mark may by
> himself manage (along with Digium) and I am trying to spark
> the discussion by which the Asterisk community may positively
> encourage Mark to recognize the scope of what is going on and respond
> accordingly. 
>
> By the same token, none of us may tell Mark how to run his business.

That is an interesting point, and possibly correct with respect to
Digium, but perhaps not with respect to Asterisk. 

Because Mark chose to open the source to Asterisk, he is not only
granting us the privilege to criticise his creation, he is telling us
that he desires and values our involvement. That's why any popular open
source software is such a threat to closed software. Crap can't hide.

As long as we wait for Mark to do all the decision-making, you are
right; it cannot grow. Once we begin to take ownership of the things
that we can do without him, that is when Asterisk will truly grow.

I don't know Mark personally, so I'm a bit reluctant to try and read his
mind, but I imagine that the success of his baby must also come with
some pain. It is hard for any parent to see their kids grow up and get
ready to move out on their own. It is also an incredible challenge for
the President of a company to deal with explosive growth.

I do not disagree with you that criticism is beneficial, but it needs to
contain seeds from which a solution may grow. I would argue that if we
truly want to contribute, we never extend a criticism without also
planting a seed - giving something towards the solution.

You think a roadmap is needed? Awesome! Propose one, including the steps
to implement it, and if it's well thought out, I'll bet it'll be very
well received. If you have skills in this area, share them!

> I also recognize the open source community resents and
> rejects the regimentaion of planning and documentation.  

I don't recognize that at all. In fact, I totally disagree. What I do
agree with is the fact that good coders are not always good planners or
documenters.

> Such
> resentment shows up, bluntly, as the shortcomings of
> Asterisk.  Mark has to delegate control and the developers
> must accept the means of delegation.

The resentment comes more, I think, from too many people complaining,
and not enough people actually contributing.

> That people who wish to document and to train newbies are
> needed is obvious as well.  

Possibly more so than developers. 

> Our attempts at turning trolls
> into customers have been quite futile, thank you ;)

Well, keep at it. That's a huge demographic.


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 30/12/2004