[hydra-dev] Still confused, but at a higher level

[Olle E. Johansson]

12 apr 2010 kl. 16.35 skrev Terry Wilson:

>> The moment we start discussing channel drivers for Hydra, it has become
>> Asterisk 2.0 and we can't convince anyone that it's something else.
>> 
>> If scalability is the keyword - define "scalability". And define target market.
> 
> 
> There is no way we could ever release a rewritten from scratch Asterisk 2.0. To truly be Asterisk 2.0, the product would need to be able to recreate all of the features that are in Asterisk 1.x. How could anyone reach feature parity with 8 years of Asterisk 1.x feature development into a year of development for an "Asterisk 2.0" that is written from scratch? It just can't be done. If Digium called it Asterisk 2.0, people would expect that it could handle everything Asterisk 1.x could handle, and then some. Hence, Hydra is not Asterisk 2.0. There is just no way we could *replace* Asterisk with the initial release. Also, some features that we have now may never make it into a Hydra release since they would be more effectively handled by an external application that communicates with Hydra (I'm looking at you, calendaring!)
> 
> In 5-10 years time will Hydra replace Asterisk for most users? My personal opinion (i am ABSOLUTELY not speaking for Digium on this) is that of course it will--as long as it runs fairly efficiently on a single box. The stability of the API and ease of making 3rd party modules should be extremely attractive to outside developers and I would expect that they would prefer working on Hydra than trying to continue to hack through the Asterisk 1.x code. But, being both a commercial and open source company I don't see how Digium could wait until Hydra reached feature parity with Asterisk 1.x before releasing it. It isn't like Microsoft released Windows NT and said, "we'll get to printing support later". They had the option to do all development in house and releasing it when it could do everything that Windows 3.x could do. Digium doesn't have 50 people to throw at the problem, as they rely also on us (still speaking in my community member role) to contribute to the development proc
> ess. Outside development is one reason why Asterisk is such an amazing piece of software. But, the downside is it is notoriously difficult to make long-term projections about where things will be. If we design Hydra correctly, I imagine other developers will see the parts that aren't there (like voicemail) and decide that they would rather not have to run Asterisk just for voicemail and will contribute a voicemail module. But why would Digium invest time and resources into replacing something that already works well with Asterisk?
> 
> So, in my opinion, discussing whether or not Hydra will replace Asterisk isn't really a worthwhile discussion topic. It certainly won't lead to anything particularly helpful, code-wise. The community will decide if Hydra ever replaces Asterisk by contributing missing pieces that Digium doesn't have the time or manpower to replace. The only way Asterisk would ever be replaced by Hydra is if people stopped using Asterisk because Hydra did everything they wanted. I can't imagine how long that would really take--if it ever happened. More helpful, I think, is coming up with what we would like Hydra to do before its unveiling--things that highlight what it can do that Asterisk can't do well.
> 
> Of course, I could be wrong. :-p

Your way of reasoning is very sound, from a very technichal perspective. I'm more focusing on the market and the community. That's my main concern.
How do we communicate what this is and what it's not?

Everyone will immediately see Asterisk 2.0 and start assuming that. Compare it with FreeSwitch, Asterisk 1.x and other solutions and we can't possibly -as you say - fulfill those expectations.
Which means that we will be hurting ourselves from a marketing point of view. "Shooting oneself in the foot" is a common expression.

On the other hand - is there any way to handle this situation differently?

Maybe not to launch it as a separate product at all - maybe something like "Asterisk Scalable Infrastructure Addon"
Make it part of Asterisk instead of something separate. Let it take over in five years.

/O