I'm currently working on my third successful open source based company. We use Asterisk and haven't needed support in years.
Sent from my iPhone > On Jun 20, 2015, at 12:57 PM, Zak Rupas <[email protected]> wrote: > > 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
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
