No offense, but that's a pretty short-sighted way of looking at things. 
Having worked in the computer business for almost two decades, I can 
assure you, businesses don't use/buy products, no matter HOW stable they 
are, if the total cost of ownership or production is too high -- this 
includes buildout costs, development, maintenance, AND deployment.

If you build a product that's super-stable and super-fast, but 
difficult, time consuming, or expensive to deploy, people will opt for a 
different solution. That's just the way business works.

Take Cray Supercomputers as a prime example. Seymour Cray built this 
fantastic supercomputer architecture, but didn't build any peripherals 
for it or even an operating system, assuming that, if people had the raw 
speed and power available, they'd be eager to use it even if they had to 
build their own hardware/software. Eventually, after three tries at 
three different companies, all with this same goal (he kept being forced 
out of his own companies for his short-sighted and poor business ideas), 
Seymour Cray's own company went bankrupt because people refused to buy 
computers that were difficult to deploy, even if they were extremely fast.

Conforming to standards is good.  Flexibility is also very good. But 
ignoring things like ease of deployment (or *cough* documentation) is 
basically just thumbing your nose at the people who actually use the 
software. ;) 

That being said, I do love the SER project, and I think SEMS has 
incredible potential, but none of that will matter in the long run if 
it's not made easy for people to use. One of the reasons so many people 
go with things like Asterisk and then try and make it work like a SIP 
proxy (which causes headaches galore) is because Asterisk is incredibly 
easy to deploy, exceptionally well-documented, and has third-party 
modules galore integrated into it to allow people to do all sorts of 
things. SER and SEMS combined, on the other hand, while fast, powerful, 
and a fully-featured SIP proxy/Media server combination, has sparse 
documentation, is absolutely painful to deploy, and has only the very 
basic few modules along with it, requiring that, for many features, you 
write the module yourself.

While I would FAR prefer the core SER coders to continue their work on 
making SER the stable, fast product it is, and in piecing together all 
the SIP RFC weirdness into an actual product, SER/SEMS could not go 
wrong by recruiting some more people to write modules, by making the 
install create basic configs that work out of the box, and by having 
detailed and clean documentation.  I'd offer my services, but my C/C++ 
coding is laughable at best (it's been 15 years since I've done any real 
C coding), and I honestly understand so little of the SER 2.0 stuff that 
my writing documentation for it would be very BAD Idea (TM). If someone 
(i.e. a coder who knows what's actually going on) were to write 
framework documentation (much like the very sparse framework docs that 
exist in the modules), however, I'd be happy to take a crack at making 
it human-readable.

N.

Greger V. Teigre wrote: