[asterisk-users] no unicall on 1.4

[Lee Howard]

Anton Krall wrote:

>This is exactly one of the things that Steve and I discussed a bit ago...
>when did asterisk turn from an open source project with very good developers
>into a business that only focuses in $$$?
>  
>

Well, I think that there can be no doubt that there still are some very 
good developers working on Asterisk, but yes, I do understand what 
you're saying, and I think that we're not the only ones that have 
noticed it. In particular I've noticed how the disclaimer requirement is 
a sore spot, and as well how impossibly difficult it is for Digium 
competitors to get their patches applied to the code base:

http://bugs.digium.com/view.php?id=7742

>That’s why openpbx was born I guess.... 
>  
>

In part, yes. I think that some of these things are like lead weights to 
the Asterisk development process - I think that Steve Underwood 
appreciated the unfettered CVS commit access to the OpenPBX repository. 
That's a once-in-a-lifetime opportunity that Asterisk may have been able 
to have, itself, possibly. I see Steve's participation in OpenPBX as a 
big selling point (i.e. real T.38 gatewaying and actual spandsp 
integration). However, there's a lot of momentum behind Asterisk, and 
that's compensated somewhat for its lead weights up until now, and 
OpenPBX can't seem to get a public release out.

At Cluecon last year in Chicago anthm told the conference how it was his 
belief that it would be better to start from scratch than to fix up all 
of the problems with Asterisk like OpenPBX is attempting - and thus we 
have FreeSWITCH.

So there are lots of possibilities out there, and I can only think that 
the lead weights in the Asterisk development process will eventually 
lead to more issues than with chan_unicall.

>For example, samba is still free, and people are making a profit from it by
>giving out consulting services for deploying samba.. that is a good working
>scenario.... asterisk used to be the same.... can you spell greedy :)?
>  
>

Well, when you sell consulting services for deploying Samba your 
business focus is still on the software. If they were selling 
Samba-related hardware or were heavily involved in selling Samba-related 
things like books and tee-shirts, etc., instead of actually working the 
software itself... well, then I think you'd see the same kinds of 
problems that you're frustrated with now. It's all too easy for that 
business activity to become a conflict of interest when it's not 
directly related to the user-experienced software itself.

Lee.