An utterly crappy day ends with some very good news. I'm so excited I mistype my post egregiously. :)
An utterly crappy day ends with some very good news. I'm so excited I mistype my post egregiously. :)
Hmmmnnn. Food for thought.
*the public switched telephone network, also known in Cisco and other circles as the POTS: plain old telephony system
Well, it's official. I'm now the president of San Francisco's Perl Mongers group. (I lost a coin toss with one of the other volunteers when the now-ex-president stepped down, so now I have to assume ultimate responsibility for getting meetings together.)
Add this to work, Dickens Fair (Fezziwig's specifically), and the work I want to do on Tricorder and Vocal, and I'm rapidly approaching overload. I haven't quite reached that point yet, or I wouldn't have accepted the post. Still, something may have to give soon. I don't want free software to be that something.
dyork also wrote:
Yet another reason for investing SIP vs. H.323 is the fact that I understand Microsoft's next version of NetMeeting will use SIP as its underlying protocol. I was told that Windows XP would ship with a "SIP-phone" included, although it is hard to understand if that is just another part of Microsoft's "Windows Messenger". In any event, SIP definitely does seem to be on the rise.
Hmmmnnn... now that's an interesting piece of news. I don't keep up as well as I should with Microsoft's plans, so I was unaware of this wrinkle.
In this case, as in so many others, MS is following the industry rather than leading it. I would be shocked if it were not using a broken version of SIP that makes compatibility difficult. However, I think this time the strategy will lose. Vendors have really taken the high road with SIP; they've worked hard to ensure compatibility at events like the SIP Bake- Offs (now renamed to SIP Interoperability Test Events after threats by Pillsbury. Is this country insane?)
When SIP vendors find a part of the standard that needs changing or clarification, it goes into an additional IETF document. (So far they've shied away from modifying the original RFC.) In general, vendors will bend over backwards to interoperate even with other people's broken stacks. I don't think Microsoft can break compatibility even if it tries.
Given that, it would be nice to have a SIP phone on most Windows desktops. It would certainly help increase the popularity of any Vocal service, commercial or otherwise.
Dang... maybe I'll have to break down and buy a copy of Windows. (I was thinking about doing that anyway so I could play with writing Unix-to-Windows-portable Perl programs.)
I think dyork may have hit the nail on the head:
There may be another issue with the VOCAL software from Vovida. It is very complex! I wanted to experiment with putting a SIP server onto our server, so I looked at VOCAL. For what I wanted to do, it seemed sort of like learning how to fly a Boeing 747 airplane just to go down to the corner store!
Someday, I hope we are able to use VOCAL, but it is a bit overkill for what I was initially trying to do. That may be part of the issue. You all have created such an incredibly large offering... it may take people a while to understand what all it can do.
That's true. It's a major problem. There's a lot more documen tation published now than there was when I left, but the very quantity and detail of the documentation is itself daunting. For what it's worth, the company had realized this was a major problem when I left. I don't know what they're doing about it now--there certainly aren't any publicly visible efforts. :(
I think this problem would be alleviated considerably if someone would set up a big softswitch as a server, then allow others to connect. The users would just need to run a SIP client, which is a lot simpler than setting up a full- featured softswitch (possibly with support for several protocols). Of course, it would be nice if someone would make a distribution of <projectVocal</project> that includes only the parts needed to run a simple client.
The more I think about this, the more I think that my work is cut out for me and no one else will do it. Thanks to people like dyork for responding to my cries of frustration; I think they are giving me the necessary kick in the ass to do this.
I hope you find a job where they appreciate your talents and give you the resources you need--or are you going to be a full-time student when you start your MSc (even better)?
Hi, rant, thank you for taking the time to read my diary entry and post a response to it. You make some good points, but I think you also miss some points of mine.
First of all, Vocal is released under a BSD-style license. Your comments don't make it clear whether you understand this--you write as if Cisco were expecting help with a closed application. I think you got the point, but I figured I should repeat myself just in case you didn't. I'll elaborate below.
Second, Vocal runs on Linux. You can sniff its communications using ipgrab and Tricorder. You don't need any dedicated hardware to run a Vocal installation. Cisco route rs are useful for peering to the "public" phone system, but that's not necessary. You can route calls exclusively over the Internet.
The last major point is that I'm more frustrated more with lack of adoption than with lack of development. I didn't really expect the free software community to start fixing bugs in Vocal, adding features to it, or otherwise contributing code. However, I'm a disappointed that no one took the code and tried to make a running installation--i.e. set up a server that would let people make free phone calls. For various reasons, a Vocal installation would be more flexible and offer a higher coolness factor ;) than other no-cost telephony resources like Dialpad.
Explaining all those reasons would entail a medium-sized marketing campaign, which is part of my frustration: Cisco has chosen to market to companies and not to the community. That strategy probably makes good business sense--what volunteer-run free Vocal installation is going to buy 200 3660s with voice modules? The business point of Vocal is, again, to sell routers. Then again, it may not be such a great strategy: Cisco may be underestimating the long-term uptick in sales that widespread adoption would bring. When Vovida started, our business people were talking about being "the next Apache", the de facto standard that dominates the market. Apache got where it is was by scoring many, many installations by lovers of free software.
Anyway, sound or flawed, the Cisco strategy has not helped solve the problem that the community does not use Vocal. Few people have even heard of it; fewer know the benefits of using it. As I wrote in my earlier entry, it gives you all the flexibility that software gives you over hardware, applied in the realm of telephony. That's probably the best way to sum it up. If you can imagine doing something with voice communications over the Internet, you can implement it in Vocal. In many cases you don't even need to hack C; you can just write VXML.
Having clarified the point about installations versus code development, I'll switch to talking about code development, since that seems to be the point of your comments:
Qbert: There are may reasons why "the community" doesn't pick up such stuff: Why should people work for free for Cisco or another company? All too many companies think free software developers are idiots. If a company wants to have that stuff maintained, they should use their own resources.
Well, Cisco is definitely not standing still waiting for free software hackers to do its work. It is using its own resources. The current Vocal release is about 12 MB, all of which was written by developers at Vovida who now work at Cisco (modulo layoffs), except for a couple of included libraries like libxml.
I'm not sure what you mean by stating All too many companies think free software developers are idiots. Are you saying that Cisco views free software developers as idiots? If that's the case, why would Cisco solicit their help?
Maybe you mean that companies view free software hackers as suckers rather than outright idiots, because they will work on code for free. I think it's pretty obvious to Advogato readers how contributing to a free project can benefit you in the long run, so I won't belabor the reasons. How do those reasons change if the free software was produced by a company? It's still free, as are the changes you contribute.
In fact, you don't have to contribute your diffs to Cisco. The Vovida Software License is a nearly verbatim BSD license, so you can keep you changes to yourself, share them with others but not with Cisco, or even sell a closed product based on them. When we made the decision to adopt the BSD license, we reasoned that people would ultimately find it in their own interest to contribute back changes. That way Vovida (now Cisco) maintains the changes for free, keeping them in sync with every new version; the onus of ongoing development is removed from the contributer. We felt no need to coerce people into contributing their changes by, e.g., licensing Vocal under the GPL.
The telecommunications world is a closed world. Most of the dino companys in that business would rather go bankrupt, than sharing knowledge with each other. Free software is alien to them, and doesn't fit into their culture. As a consequence, they don't give anything back to the community. Why should the community give something to them?
You're right, the telecommunications world is largely closed. It's a problem. I don't see why you should make the situation worse by penalizing the one company that is trying to do things right by offering a major open-sourced codebase.
If you're saying that this is part of the reason no telecom companies have worked on Vocal and given changes back to Cisco, you're right. If you're saying we should punish the telecom industry at large by refusing to contribute to a application even though it's open-source, I don't understand you. It's comments like this one that make me wonder whether you missed the fact that Vocal is free software.
There is no incentive in working at that code. No fame to gain, no recognition, no itch to go away.
That may be true. On the one hand, there's a large codebase already. No is going to become famous for writing Vocal; it's already been done. Hmmmmmmnn. I think you may have hit on one big reason free projects by commercial companies receive so little developer attention. On the other hand, it doesn't explain why people continue to make small contributions to Linux and FreeBSD. Maybe we're dealing with two different kinds of fame-seekers here. One kind wants to write a major project with relatively little help. The other is content to contribute to an already- famous project (which is almost always much more useful). Neither kind would want to contribute to Vocal, since it's not famous. Maybe if more free software developers worked on Vocal it would be more famous, but we have a chicken-and- egg problem with these particular coders who are motivated by fame.
On the other hand, I do think the first free Vocal installation could cause a stir. Imagine the coolness value of announcing, "Here's a server you can use to talk with your friends long-distance. It's free, like IRC. Oh, by the way, it's based entirely on open-source software."
I also think there are itches to scratch with free voice over IP applications. How about the ability to talk to relatives in other countries for free? Hmmmnn, that sounds pretty appealing to me. Sure, you can do it with Dialpad et al., but you can also serve HTTP with Cern or one of these. You can do it better with Vocal, just as you can do it better with Apache.
People in need for such stuff are usually working for the competition.
Ay, there's the rub. We hoped that we could widen the interest to include people who don't write telecom software for a living. So far, we've failed. We also hoped we could convince competitors or partners to use our software, since it's free, standards-compliant, already written and tested, and high-quality. If we could get them to use Vocal, we would know that we had systems that were compatible with Cisco's SIP- running routers, which would mean we might be able to sell some routers. Hardware competitors would want to use their SIP-running routers instead, but software competitors... Well, they'd have to add some value to compete with our free product, but if they could do that, they could keep that value proprietary and buy our routers. It remains to be seen how well this strategy will work.
They have their own systems and implementations to take care of. Which is already difficult and tedious, even if you have full control over the development process. Why should people work on competetor's stuff?
Well, it depends. If you're using your own legacy codebase, you'll probably find it easier to build on that, instead of using Vocal. On the other hand, if you're starting from scratch and you need the functionality of one of the many protocols for which Vocal provides stacks, or if you want a softswitch, why would you not use Vocal?
You see, part of our strategy was to enable new service providers to rise and challenge the "dinos" of circuit- switched telephony, as you rightly call them. We wanted to create "disruptive" software. In this respect, we've been moderately successful. At least one company is offering professional services for Vocal (among other voice over IP software). We also hoped that ISPs would adopt our software and use it as a competitive edge, since vanilla Internet service is so commoditized.
Voice over IP Signalling Protocols
Telecommunication protocols are huge, complex, and described in fscking pervers standards.
I don't know, what's so bad about telecom standards? H.323 is admittedly pretty gnarly, since it depends on ASN.1 encoding. (H.323 is also not an open standard by my standards ;) , since you have to pay the ITU to view the specs, let alone to contribute to their definition). SIP was invented partly as a fix to these problems. It uses text, so it's human-readable on the wire. In fact, it's designed to mimic HTTP for maximum readability and ease of implementation. It's an IETF standard, so it's as open as you can get. Try reading the specification; it's remarkably simple. I read it during my first week at Vovida and grokked it right away, with no experience in protocol design or telephony (just a general programming background from college).
It's no accident that Cisco chose SIP as its preferred standard for voice over IP. Around mid-1999 the industry at large made the same choice, for the same reasons.
Why should people expose themself to that pain without at least getting paid?
Why should people write any software without getting paid? Do you think that the W3C standards Mozilla uses are less "perverse" than SIP? Yet Mozilla gets a lot more attention from hackers and users than Vocal. Something else is going on.
You don't get most of the standard documents for free. Why pay a fortune for this horrible stuff out of your own pocket?
Well, that's an excellent point. It's a pity that H.323 is not free. On the other hand, MGCP and SIP are. You need just one to implement a full soft switch; they're competing protocols. (You know, the great thing about standards is there are so many to choose from. ;) ) As I mentioned before, SIP is winning, largely because it is the easiest for humans to understand.
People just don't have the equipmment to test or make use of the protocols. When was the last time you build your own terminals or switches? How many real time protocol analysers do you have at home?
Anyway, thanks again for reading my diary and responding. It's good to have feedback; it's certainly stimulated me to add some detail about Vocal, and it's helped me see where I omitted information I should have included (e.g. the bit about VXML.) If nothing else, at least one more person is paying attention to Vocal now! ;)
Birthdays are a good time for reflection. I wrote up a summary of my free software activities and my experience at Vovida/Cisco. In the process I got frustrated with the adoption of Vocal and wrote a call to action, visible in the notes section of my page. Here is this wonderful open-source technology, a huge gift to the community, and almost no one has heard of it. Cisco is marketing it to systems integrators; in the meantime the free software community has fallen by the wayside, after the initial disappointment we felt when people didn't hop on the bandwagon.
It's an interesting lesson that we released a huge project like Vocal and saw so little community response. Part of the reason, of course, is that the telephony business is so specialized, an niche engineering domain separate from free software. Still, it's very hard to build a community by fiat. Other commercial open-source ventures have had the same problem. For all the talk about their power, self-organizing processes are hard to control.
I have the feeling I will have to promote it to the community myself. First I can write an Advogato article; next I can start a home page for community Vocal installations; finally I can come up with a working installation. That's a lot of work. How much of it I do remains to be seen. I may end up pursuing my tentative plan to scale back to part time at my job and devote the rest of my time to free software. It will take some significant belt-tightening. (Living in San Francisco is not cheap.)
Today I registered to vote. Of course, my life being what it is, I had to wait till the last possible day to register. Here in San Francisco, the City Attorney is up for election, and there are ballot measures about establishing a Municipal Utility District (basically a democratically elected board that takes charge of power generated in San Francisco and sells it to San Franciscans, thereby bypassing PG&E).
So I banged out a Perl-Tk program to wrap ipgrab and display its output as a call-flow diagram. It took about three days because I was over-zealous about parsing the SIP and SDP messages, and I made my usual stubborn mistake of writing the whole thing before debugging any of it. Anyway, it was still having some bugs at the Friday afternoon deadline. I was most frustrated.
I felt a little burned out, so I went to the liquor store with Mike and we played Beer Pong. This entails placing an open beer on the ping-pong table in front of you, then playing as normal, except that a hit to your opponent's bottle or can (except on a serve) results in a one-drink penalty for him. Losing a point also brings a one-drink penalty. Hence it is possible to make your opponent drink twice with (e.g.) a shot that hits her side of the table, bounces once, hits her beer, and caroms off the table before she can return it.
In this manner Mike and I got uproariously drunk. Then, around 12:30 a.m., I returned to debugging. To my amazement, I found three bugs in deeply nested code and nailed them in about 40 minutes, bringing the program up to the milestone requirements. I hung around reading till I sobered up, then drove home victorious.
The moral of this story, I suppose, is that sometimes being able to hold the whole program in your head is a bad thing. Just as when you edit your own writing, your vision is obstructed by your mental image of your work; you see what you thought, not what you wrote. A little chemically induced impairment can hobble your brain enough that you see only the code in front of you, bugs and all. Friends don't let friends drink and drive, but you might just say yes to coding drunk. :)
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!