As I wrote a couple of days, I’m currently in the process of evaluating the PIKA WARP appliance. As I already said before, the PIKA WARP isn’t a real PBX, but actually a framework for building PBX type appliances.

For me, the entire evaluation process is more or less a process of trial and error, trying to figure out how the box is built, both from the software side and both from the build-tools provided with the appliance.

The process of flashing the new FreePBX based images wasn’t much of a hassle, actually, after more or less fucking up the box a couple of times, I became fairly handy with both the warploader and uboot tools, used to flash the onboard flash memory with a new boot image. After flashing the FreePBX about 3 times, I got it to come up right on my browser window, which produced the following screen:

PIKA FreePBX Screen

Now, it was fairly clear to me that MySQL (a mandatory component of FreePBX) isn’t a shoe in for the WARP appliance, after all, for an appliance it would be a blowtware. So, FreePBX here comes with SQLite, which on the surface should provide for similar functionality. Having worked with SQLite in the past, I knew for fact that some portions of FreePBX will not work – who am I kidding? if they would work it would be the most amazing thing I’ve seen a long time.

Mainly, this is caused by variations between the SQL code and various table management that FreePBX imposes on the FreePBX database structure, when installing or upgrading new or existing modules. For example, trying to go about and install the FreePBX IVR module yields the following error:

FreePBX error on WARP appliance

Well, that’s understandable – basically means that the unit isn’t yet fully useable with FreePBX – but we are getting there I guess, after all, rome wasn’t built in a single day.

For a while now I’ve been toying around with the idea of utilizing Lighttpd for various web based applications. One of these application is my Automatic Dialer framework, also known as the GTD-API. The main issue with the GTD-API (besides that it is highly reliant on a MySQL database), is the fact that all requests have to be processed via XML-RPC HTTP post requests.

The main issue that I had was this: in a production scenario, a dialer management system will generate over 100 requests to the XML-RPC server. While Apache is fully capable of rendering services at such a speed, its increasing size and boilerplate automatically introduce a management issue. In addition, as I was trying to build a dialer appliance that can be used in any enterprise, the ever expanding Apache wasn’t a good choice.

While I was looking at both NginX and Lighttpd, the latter captured my eye, thanks to a simple advantage – The integration of FastCGI based PHP was so easy, that it almost troubling that I used Apache all these years.

At this point, once I got Lighhtpd working with my Dialer, I said to myself: “It would be really cool to go about and send status reports back from the dialer, directly to the web client activating the call. In addition, I really don’t want to go about and perform these updates to the database, then query the database – that would, literally, kill the MySQL server.

So, I implemented a local session storage area for each call, which updated the call status as it traverses. The information was stored on the hard drive, which allowed a better response time than the ever indexing MySQL server. The status reports were picked up from the Lighttpd server via an Ajax client (which I didn’t write – I suck at JS) – and it works quite well.

I wonder, can Lighttpd completely replace Apache? … time will tell…

When people hear other people talk about “The Annoying Thing”, most probably the first thing that pops into their mind is the below video:

However, today I’d like to refer to another annoying phenom, the one that I call: “letting the piss get to your head – even if you didn’t do anything or contribute to anything!”.

As I am a consultant, I work with a multitude of customers, each one with their own craziness and weirdness. Now, there is nothing wrong with being weird or crazy, but being out blunt rude and insulting, that’s something completely different. For example, when I walk into a meeting, I have the best interest of my customer in mind, however, when that customer mistakes my willingness to assist and promote his company, mistakes that willingness to being a sucker – that’s annoying.

Why would an IP carrier tell something in the form of: “Haaaa… Are you kidding? they need to pay me for using their product, I’m promoting it!” – that’s plain rude. Fuck man, your founders built your entire company on this product, when they raised VC money and charged money from their customers, the makers of the product (an open source one), didn’t make a dime of from you. That statement is blunt out RUDE!

I think that the best option would be to go about an establish inside the Open Source license model a statement that says: “If the GPL product is used in conjunction with a service, that surpasses the size of X concurrent/registered users, the product shall no longer be considered a GPL product – but a comercially licensed product, requiring the user to pay royalties to the creator”. Why is this a good thing? – very simple, sustainability of Open Source. In one of my previous posts, I talked about the sustainability of Open Source – defining the border when a usage of an Open Source product is considered commercial – and requires a form of royalty payment to the project’s maintainer/creator is a crucial element in making sure the project continues and evolves.

Imagine for example, that the Apache foundation didn’t exist. The foundation supports and funds (partially) the development behind the Apache web server project and related projects. The project is capable of sustaining itself, as companies which are making commercial usage of Apache are taking an active part in the funding of the project. With the Apache project, there was no need for a definition of “Commerical Use”, as the Apache project started from a Commercial need. Other projects start from non-Commercial needs, but evolve into Commercial products – that case needs to be addressed.
 

While Open Source projects around the world gather up the troops and become recognized for what they are: highly polished, highly effective, extremely economical products – the situation in Israel is fairly different. We’ve all heard about companies like Zimbra (recently acquired by Yahoo), MySQL (recently acquired by SUN) and others, which had struck BIG TIME. However, the situation in Israel differs immensely.

I’ve been invited to participate in a panel at the Garage Geeks, to discuss the various aspects of Open Source sustainability. I’ve made it my business to build a business completely surrounded by Open Source, devoted to the promotion and adaptation of Open Source – and when possible, the promotion of Open Source licensing models and the understanding of what they mean.

In one of my previous posts, I’ve indicated that Open Source projects are highly exploited in an illegal manner in Israel, thus, making Open Source business in Israel a high target for Open Crooks. The question immediately arises, how can an Open Source project become successful? In addition to that, what are the factors that make a good Open Source project a grand Open Source project.

Step 1: Features

For an Open Source project to become popular and frequently used, it should have an extensive range of features, which is constantly being upgraded and enhanced. Taking from my own personal favorite, let’s take a look at Asterisk – the Open Source PBX. Over the course of the past 5 years, Asterisk had evolved to include hundreds of features. Each new feature in an Open Source product expose it to a new market. With Asterisk, the introduction of an Answering machine detection tool had introduced it to the automatic dialer and contact center market. The introduction of LumenVox speech recognition had introduced it to the ASR market, and so on.

While features are important, it is also very important to make sure the features included are features that the community and users require. While it is really cool to have a mod_kitchensink for the Apache web server, no one really uses it.

Step 2: Community

In order for an Open Source product to become successful, it MUST have a vibrant and active community – better yet, more than one. While an active developer community is important for the advancement of the project, a set of auxiliary communities is required. A users community is a must, rendering support and usage ideas to its members. No less important is a business oriented community, one that speaks to the manager level people, those making the decisions in organizations. Tap into that level, and the Open Source project is now gaining followers from other side of the border.

Managers tend to be highly traditional in thinking, not inclined to utilize Open Source at first try. A vibrant business community of the Open Source project can do wonders to the project, especially with its promotion and adaptation into existing and new business structures.

Step 3: Funding and Sustainability

Funding an Open Source project doesn’t entirely mean – MONEY! Well, eventually it does mean money, but not in the normal way we think or work with money. Open Source developers don’t work primarily for the money, the driving force behind Open Source developers is different. Question be: “If Open Source developers aren’t motivated by money, why would you need funding?” – the reason is simple, the surroundings of an Open Source project require funding.

The surroundings of an Open Source project mainly include the following: public events, developer meetings, servers, hosting, travel fares, participating in trade shows and others. All of the above are generally associated with Marketing, however, marketing an Open Source project is sometimes as important as the project itself. If we are to examine the growth of the Linux community and user base in the world, we are mainly thankful to RedHat in its early days (1996-2001), closely followed by Debian with its recent off spring Ubuntu (2006-2008). Imagine, you can now go into an IBM dealer and ask to buy your notebook with Linux, how cool is that? how did that happen? did the world suddenly realise Linux is better than Windows? – the answer is NO! The marketing efforts of these companies had proven worth while, as the concept of using Linux as a desktop became common in recent years.

Step 4: Training and Certification

If your Open Source project is UberGeek targeted only, than you have a very slim chance of making it big. Lowering the bar on the requirements for the adaptation of an Open Source project is highly important and can be mostly achieved by training and certification. The training makes it possible for people to learn more about an Open Source project, while the certification makes the project seem more desirable and exclusive.

Why do people seek M$ and Ci$co certifications? simple, because they know these certifications mean something to manager level people and decision makers. The certification is a written (actually printed) proof that you know what you are talking about and that you are truly a professional working in the field of that Open Source project.

Conclusion:

If all of the above are met, you are surely on your way to create the next big Open Source project – and you are on your way to world fame and rock-star feeling.

What would you call a platform that is made up of multiple elements, each one connected one to another by a very thin line of integration – having each one reliant on the other for proper functionality? – A MESS!

Recently, a customer of mine had asked me to review a platform that he has, that had been built by another integrator. According to the customer, the platform was built on top of an Asterisk + MySQL stack, with an Apache based front end. I had asked the customer to send me some code segments from the platform, so that I may have a better view of things. The code segments that were sent had suggested that the platform isn’t far from the description. Asterisk is indeed the main IVR core, MySQL is used as a database, and it would appear that the scripting language is PHP – all is good, looks fairly nice. So, next step was to logon to the actual platform and take a closed look…

At this point, all hell broke loose! Aparently, the web front end was based on a Python based engine called django. While django was an interesting piece of code in terms of learning it and maybe using it, the immediate meshing of django into the IVR application framework didn’t make any sense to me. In addition to that, I’ve come to learn that there is also an Oracle database server installed on the system, running some funky JAVA server, that was communicating with the IVR application, via a very flaky interface. In other words, the platform is a mixture of technologies, integrations that are done in a none standard way and worse of all, no documentation anywhere in the code about how it works.

Now, the customer wants me to take control over the platform and to assume responsibilities for it. My immediate answer was a big NO WAY! Imagine that you need to take responsibility for a child that is not yours, one that you know for fact that is prune to burn down your house, as he shows clear signs of pyromania – would you assume responsibility? I don’t think so. So, I tell the customer all the facts and the customer says: “I don’t care, I want it in working condition, ready for production in 7 days!” – in other words, and impossible mission, especially with all the decoupled technologies within the application framework.

What would you have done?