I read this to essentially mean ".....if Mitel can't make money off of it, 
then you cannot use it.." 

Gee, what a surprise to some, perhaps not such a surprise to others.

I *DO* really think it is sad to pretend that this is a matter of "...visions" 
vs. "hard reality" when a decision to allow blades to accept/work 
with/utilize items from un-authorize sources is a coding decision as is the 
reverse.

Or MAYBE I am too dense to understand this.

Bob Finch


On Thursday 16 January 2003 10:43 am, Dan York wrote:
> >     So, just to make sure I understand this clearly:  In spite of
> > everything you've (plural, not you in particular, Gordon)
> > consistsently told us for over a year, there will _not_ be a
> > mechanism for community-developed, unsupported blades?
>
> That's correct. Mitel will not be providing such a mechanism. We will
> continue to host contributions on our FTP and web sites, but we will
> not be providing an automated method to install unsupported add-ons.
>
> > This is
> > somewhat disappointing, in light of the clear, unequivocal, and
> > repeated statements that such a mechanism would exist, and would soon
> > be well-documented.  I can understand a number of reasons why you
> > might make such a decision, but the reversal is somewhat troublesome.
>
> I understand your disappointment.  When we first announced the blades
> interface with version 5.0, we had a very grand vision of how it would
> evolve.  In our excitement about the possibilities, much of that vision
> was communicated by Gordon, myself and others in this and other forums.
> Unfortunately, that vision ran straight into the cold, hard reality that
> in an economy such as the one we are in today, there is little room for
> grand visions that don't translate directly into revenue.
>
> As a commercial enterprise, we have to focus on the needs and wants
> of our commercial customers who ultimately enable us to continue
> working on this product we love.  As the ranks of those customers have
> grown with our continued success, so have the requirements that we in
> product management have to address.  When we look at the limited pool
> of developer hours we have to work with, we have to make some
> extremely tough choices.  Unfortunately, that means that some of our
> grand visions have to stay as exactly that.
>
> Regards,
> Dan


--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org

Reply via email to