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

David Vossel dvossel at digium.com
Mon Apr 12 09:54:54 CDT 2010


----- "Terry Wilson" <twilson at digium.com> wrote:

> > 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
> 
> Terry

Well written Terry, I completely agree!

~Vossel





More information about the asterisk-scf-dev mailing list