When Freedom Rings
I was both surprised and pleased with the community response to the announcement for GNU Free Call. Rather unfortunately our hosting for the wiki, Ibiblio, was down, as they were doing a large move on Tuesday. Even more amusing, Haakon’s email provider also decided to do some relocation this week.
With the many comments I received, it is clear to me some are best answered on the wiki, especially now that it is back. This includes things like a more detailed project roadmap, which Haakon has been hard at work updating. Other things are probably best handled through the mailing list (sipwitch-devel). In particular, I think many concerned issues that either were not well explained in the FAQ attached to the original announcement, or not covered at all, and so I think we need to have a new or further extended FAQ on the wiki for GFC.
What I wanted to talk about right now is some general things in GNU Telephony as a whole. In particular, there are a few things in development now, and some of them do require additional help.
The first of these is an effort to consolidate GNU Common C++ with GNU uCommon, and have the entire ZRTP stack build under cmake. There already is an experimental branch in svn for a ucommon library that also builds commoncpp, and an experimental branch of ccrtp that builds against that. I am hoping to see this released for ucommon 4.2, or maybe 5.0, as there are also some abi issues I would like to change in ucommon itself.
I had asked Simon L’nu to help me coordinate establishing a public portal so people could create accounts and connect through sipwitch to each other securely such as with a ZRTP enabled SIP client, as well as receive calls from the general public under a public sip uri, if they so wish. I also want to use this to coordinate internal project communications, and I have thought about setting up freeswitch as a conference server backend for this purpose. But we do not yet have a public site to run these things at, though several nations, including the Cherokee of Idaho, have asked about possibly helping with this.
There is also an experimental sipwitch gui that has been started, in Qt. This may eventually become a desktop Gui to match Haakon’s very impressive vision, but initially it may only exercise some core sipwitch services for desktop users. At least it is a starting point down that path.
I had also thought about writing a wiki document explaining our policies and coding practices. Most are essentially the same as used in the GNU project, especially when speaking of packages that are already part of GNU proper. However, in some of the newer packages, we may diverge in some areas as is convenient for our users so long as there is no effect on freedom. For example, much like in KDE, there is a growing tendency it seems in GNU Telephony to prefer cmake over autotools.
For those who have offered to help with GFC, I especially appreciate that. I hope all can join the mailing list, so that it will be easier to communicate and collaborate together in freedom.
March 22nd, 2011 at 1:25 pm
The mention of a GUI (Qt a good choice I think) is reassuring.
My biggest concern with this great sounding project is ensuring it is easy enough that the likes of my mum can pick it up and use it easily (she’s over 70). For it to work it has to be a very simple utility not something for which people need to read a 10, 20, 1000 page manual.
It’s certainly got me very interested to roll it out to my family and encourage friends to use if it’s easy enough to set up a suitable plug server they can all use for introductions (I’m not totally clear yet on how that works so that’s a little bit of a guess).