bkml wrote: > had qualities. Whilst this was a lot of rhetoric on his part, I fully > subscribe to the view that old means more mature and that new means > inexperienced and prone to risks and fallacies. Perhaps, there should > be more appreciation for slower pace, less bleeding edge and more > maturity.
There's a difference between mature code and abandoned code. I'm not suggesting we use bleeding edge, but to the uninitiated, the OpenPBX project looks pretty dead - wiki is out of date, mailing lists are all but dead, Trac is overrun with spam, #openpbx occasionally sees some tumbleweed rolling by. One could be forgiven for thinking that OpenPBX is no longer being actively maintained by anybody. > The trouble I have with the way the Asterisk folks are fixing bugs is > that I have quite often seen a bugfix break something else. Not my > idea of bug fixing. It's often a matter of the devil you know versus > the devil you don't. Adding bugs while you fix bugs happens in most software development. As long as you fix the bugs you add, and the overall direction is forwards, isn't this how software evolves? Isn't that why it's called "development"? Look at the bugs that get introduced into the Linux kernel as it evolves. Next release, those bugs are fixed, some new features (and maybe some new bugs) are added. As much as Asterisk might be adding new bugs, they're fixing old bugs... and at least code is being written, whether it be bugfixes or new code. If we didn't dare write new code for fear of introducing new bugs, then I guess COBOL and FORTRAN programmers would still be in high demand. > I have recently been doing quite a bit of work on channels and ISDN > integration and the more insight I gained, the more apparent it > became to me that nothing quite matters as much as the Unicall > concept to make all interfaces look exactly the same to the telephony > engine and translate or simulate capabilities into a coherent unified > virtual interface layer. Sounds great. But can you convince others to share that opinion, or is this a one-man crusade? > The value of Unicall cannot be overemphasized. It is far more > important than whatever Freeswitchers are raving about. Without > something like Unicall, Freeswitch is going to ultimately run into > the same trouble Asterisk has. Hopefully some Freeswitchers are reading this list then, and give some thought to that advice. > Freeswitch has its place, but OpenPBX also has its place. With all > due respect, I don't think there should be any lets not do OpenPBX > any further, lets merge it into Freeswitch talk on this list. My point was that right from day one, there was an alternate plan for OpenPBX to use an alternate core. I didn't suggest merging with FreeSWITCH. I suggested FreeSWITCH as a possible alternate core, and the development of modules to wrap around FreeSWITCH - essentially, OpenPBX VoIP applications sitting on the FreeSWITCH "OS". > You can always replace the rusty pieces with stainless steel, one > piece at a time. If you have the tools to do it yourself, then this > will keep you from having to spend the money on a new car, while you > can still drive the old one as you are gradually rebuilding it. Rebuilding the Asterisk core piece by piece could take years (especially if the number of OpenPBX developers continues to dwindle), and don't forget that Anthony considered (or even tried) doing that. He came to the conclusion that it was just too broken to be fixed, and that it was easier to start from scratch. So, while you rebuild your car one piece at a time, five years later when you've finally finished it, you might find that you can no longer buy gasoline to run it on. That could result in a lot of hair tearing-out. In the meantime, the VoIP market is exploding, and people don't want to wait that long. You might have all the time you want if this was a university research project, but in the business world, customers want solutions on a deadline. If one option can't provide that solution, they'll simply choose another one, even if it might cost more money. The cost of downtime may be more than the initial outlay of a different system. > I personally would love to see LESS features and a more generic and > universal call model instead. Some other people will want to see lots > and lots more features. Yet more reason to have several different and > distinct projects to accommodate different views. Less features is exactly what FreeSWITCH is doing. They don't want to be a PBX - they just want to be a softswitch. Inevitably, PBX modules will be written by the community to run on top of FreeSWITCH, but that doesn't make those modules a part of FreeSWITCH, just like Apache is not part of the Linux kernel. A stable ABI is one of the goals of the FreeSWITCH core, which also makes it attractive for commercial developers to write closed source modules that sit on top. Considering this scenario: you buy a Cisco 2800 series router for your VoIP to PSTN connectivity, and you run phones directly from that router. You have basic IVR, and you can add voicemail by adding an AIM module. Or you buy a dirt-cheap Linksys SPA9000 with voicemail on a USB key and run your office from that. Cheap VoIP "black boxes" are appearing on the market very fast, and some of them are cheaper than the cost of a PC to run Asterisk / OpenPBX / FreeSWITCH. The only way that open source VoIP can stay ahead of these cheap commercial offerings is to out-innovate them, which is hard to do if you're still changing the head gasket on your reconditioned engine. _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
