At GreenfieldTech, we take high pride at the “no hidden costs” methodology. This means that when you get a price quote, you’ll get a complete price quote for everything, ranging from consulting, through development up to install and support – nothing is left out, nothing is left for chance. Initially, it makes for a slightly higher price, however, when compared to other price quotes – it is simpler to read and to the point. However, most companies don’t work in such a methodology, thus, the price quote will usually be based upon “The umbrella concept”.

The manual opening umbrella

The manual opening umbrella is one of the oldest methodologies in the world, and is taken from the world of construction. The idea is very simple: the customer receives a highly enticing low entry price and pays an arm and a leg for each change or addition.

Many solution providers who utilize this methodology do so by simply creating an overly complicated price quote, a highly detailed specification document that doesn’t say much – usually followed by the ever annoying sales person indicating that: “oh, that’s not covered in the original quote, that will be an extra”. Solution providers utilizing this methodology usually do so due to a simple fact: “They have no clear solution track or a clear view of the end goal”. The project would usually lengthen beyond the projected time scale, usually by a factor of more than 30%, ending up in losses or law suits.

The customer will usually try to protect itself by contractually obliging the solution provider to a specific end of project date, with specific penalties. However, my experience shows that while the penalties are fairly often utilized, these are not utilized to the fullest – mainly due to the fact that the customer wants the project completed, while the solution provider may halt the project pending a proper ruling on the the matter – in other words, the customer is in a lose-lose scenario.

The spring opening umbrella

This methodology is slightly faster than the previous one, where the solution provider will provide a slightly less complicated price quote – however, will include many disclaimers into the price quote – indicating various changes of pricing and high margins of price change at will. The most common practice for this methodology is to indicate that: “Actual price will be calculated according to the actual work performed”. This methodology is very much common in the “Work-Only” or “Consulting” business, where there is no set time frame. What happens many times is that the consultant would linger the initial contracted work, then, as the contracted time reaches its end – it will “spring” out a new indication that a new purchase order is required. Now, working according to the above methodology seams like a good way for the customer to protect itself, however, in many cases – it is exactly the opposite.

So, what are we supposed to do?

A good consultant should be able to distinguish between a “project base” job and a “hours basis” job. When choosing a consultant, verify that his history of projects is versatile, which means, that he’s able to acustom himself to your requirments – both technical and financial. Flexability is a virtue, however, if a consultant is too flexible, it is usually an indication of poor experience or complete lack of it. Most consultant who are taking a certain job “type” for the first time would lower their cost, mainly to get the job – however, they would utilize their customer to “learn the ropes”. There is nothing wrong with learning the ropes on your customer’s expense, as long as the customer is aware of it.

Remember, as consultant we have duty to our customers first then to our business. Sure, we are all in this for the money, after all, that’s what puts food on the table and pays the bills, however, the needs of your customer come first. If you are unable to price a project on your own, consult with other freelancers and reach out to them. Tell them your story and your dilemma, usually, someone had already encountered such an issue in the past – and will be able to render a solid and useful advice.

In this case, I’d like to examine two of the Open Source projects I’ve lately been utilizing more and more, mainly Kamalio (AKA: OpenSER) and AdHearsion. These two project represet two edge cases in the Open Source world. While OpenSER is strictly a SIP Proxy and Registrar, controlled entirely by a configuration file and database, AdHearsion is a programmatic API based on Ruby, built to provide developers an easy traversal into the Asterisk and Open Source telephony application development world.

Kamalio (AKA: OpenSER)

While Kamalio (AKA: OpenSER) is one the more popular SIP proxies of the world, it’s documentation lacks proper configuration examples. If you visit the Kamalio project website, you’ll find a mixture of documents, describing the various features and how to activate these. You will find some simple to following guides on how to integrate Kamalio with other projects, such as Asterisk – however – there are no easy to follow, beginner level tutorials.

This reminded me much of the Asterisk early days, where the dialplan language seemed like this horrific mixture of INI type directives and formats and the logic behind it illuded most people. As time progressed, many people started donating documentation and configurations examples to these, many companies started rendering Asterisk support and consulting services and slowly Asterisk became more and

more widely adopted.

For some strange reason, the community surrounding the Kamalio project doesn’t provide documentation that is usable by newbie users. Think about it, if I’m a newbie user, what kind of documentation am I looking for:

• Compile, install and execute Kamalio correctly – documentation for this is available.
• Setup a basic system for routing calls between registered users – documentation is available.
• Setup a basic system to route calls outbound to the PSTN – documentation missing.
• Setup a basic system to support Radius based AAA functions – documentation missing.
• Setup a basic system to support internal and external call routing – documentation missing.

In other words, three of the most basic tutorials are simply missing. One may argue that Radius isn’t basic and that MySQL support is more basic and provided – true. However, if I’m trying to integrate Kamalio into an existing ISP/Carrier infrastructure, it is fairly basic that I already have a RADIUS server on the network – and I’d like to use that.

The only piece of valid documentation that I managed to gather was a book from Packt Publishing called: “Building telephony systems with OpenSER”, and even that talks way too much about MySerWeb, a WEB based frontend to OpenSER.

Adhearsion

I admit it, I’m an Adhearsion newbie – well, I’m also a Ruby newbie – but that’s something completely different. Before we start talking about Adhearsion’s documentation, let’s talk about something really annoying about the Adhearsion website – the URLs are confusing!

If you go about and browse to http://www.adhearsion.com, you are automatically redirected to http://jicksta.com/, which is Jay’s blog. Now, as much as I do respect Jay, this is a really weird way of getting people to visit your blog – isn’t it? Now, if you visit http://adhearsion.com, you reach your true destination – The Adhearsion project home page. Ok, I may be nitpicking here – but I’ll write this off as a configuration error somewhere (DNS, Apache, index file, etc).

Now, Adhearsion is a wonderful example of how to do documentation for a project: easy to follow tutorials, a full API documentation (slightly complicated to follow, however), an installation guide that even a newbie can follow in 5 minutes – in other words, all the makings of a really usefull tool, built by people who have usability and ease of development at their priority.

I really hope that as time progresses, we’ll see more documentation on the Adhearsion website, especially one that is pointed at real newbies. A tutorial that I feel is in order is “Adhearsion for PHPAGI developers”. The traversal from PHP to Ruby is hard enough, so traversing from PHPAGI to Adhearsion is a complete change of though patterns and skill sets.

You are probably wondering why I’m talking and learning Adhearsion, after all, I did write a book about PHPAGI. Well, after meeting Jason Goecke at Amoocon, I’ve been convinced by him to give Adhearsion a try – and I’ve decided to adopt it. I’ll be launching the www.adhearsion.org.il soon (well, at least the minute I fee comfortable with Adhearsion).