I agree with Peter. The company's I worked for in the past that deployed open 
source never made it as they encountered serious issues and bugs and did not 
have a solid in house talent that could resolve the issues. There is only a 
hand full of large carriers left with open source cores and they spend more 
money retaining talent to manage and solve issues vs going with a known canned 
system that will do the support etc

Just my 2 cents for what it's worth


Thanks
Zak Rupas
Tier 3 Voice
Vonage

> On Jun 20, 2015, at 12:47 PM, Peter E <[email protected]> wrote:
> 
> Well said Alex. Service providers require support for the *whole* product and 
> that is where open source solutions may falter.
> 
> I don't necessarily agree with the notion that the big-brands don't 
> integrate. We do a ton of integration with Broadsoft, both with software that 
> we've written and 3rd party software. While they're not perfect (who among us 
> is), and they're not cheap, they are highly scalable, reliable, and yes, 
> extensible.
> 
> I am also a big fan of open source where it makes sense, but for our core 
> soft switch, no.
> 
> 
> On Jun 20, 2015, at 11:34, Alex Balashov <[email protected]> wrote:
> 
> Indeed, it doesn't seem to me that open-source systems are the thing to be 
> avoided, nor that it's necessarily possible to do so. Moreover, the value 
> proposition and trade-offs of open-source systems are quite clear. It seems 
> to me the largest long-term value is in integration paths and connectors; 
> most proprietary, "big iron" boxes just do what they do, and that's all they 
> do, more or less. They may have a lot of features, but that's the feature 
> set, and tying it together into novel, innovative and commercially 
> differentiated third-party services is hard.
> 
> That said, I think we all know the sort of open source-based system to which 
> the OP was referring. Asterisk and FreeSWITCH are low-hanging fruit, and have 
> invited a lot of bad implementations and poor architectures. There's nothing 
> wrong with using these systems foundationally within a carrier-grade product, 
> as long as the system is architected correctly, in a horizontally scalable, 
> distributed and fault-tolerant way, and that's a fairly complex undertaking 
> of software engineering.
> 
> Vendors of these kinds of solutions also often do not provide a level of 
> support that comports with telco sensibilities; their reasoning is either 
> that the customer should largely support it themselves, since it's all built 
> on open-source components, or their scope of support is narrow. Consistency 
> and commitment can be an issue.
> 
> I can only speak firsthand, but in our case it has been very clear to me 
> since the early life of our open source-based, commercial ITSP product that 
> customers expect a high level of service value, and that the vendor 
> relationship, along with the institutional domain knowledge and expertise 
> provided, is as much a part of the value proposition as software itself. It's 
> also been very clear that they expect support for the _entire_ technology 
> stack of which the product consists, much as they would receive from Acme 
> Packet or Sonus. Our customers don't care that our product ties together 
> Kamailio, SEMS, PostgreSQL, Node.js, Redis and, ultimately, Linux, nor do 
> they care about the degree to which we can or cannot exert direct control 
> over bugs in these third-party GPL components. They expect us to configure 
> the installations, maintain them, and troubleshoot, debug and fix as 
> necessary.
> 
> I don't think this insight is necessarily common among vendors of open 
> source-founded products. I've heard a lot of things like, "Oh, well, that's a 
> bug in Asterisk, that's not a problem with our application." If the vendor 
> sells and supports an Asterisk-based platform, to a large extent, it should 
> be the vendor's problem. They may not be able to resolve it themselves, but 
> they should own it, communicate it efficiently to the appropriate parties 
> through expedient channels, and marshal the appropriate resources in support 
> of fixing it. Not everything is always possible, of course, but many things 
> should be possible most of the time.
> 
> -- Alex
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 303 Perimeter Center North, Suite 300
> Atlanta, GA 30346
> United States
> 
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops

Reply via email to