After three days in New York (business and visiting old friends), I am on the way to Parallels Summit 2009

For quite a while it was quiet on this blog. This does not mean that we forgot about it :). The truth is that we are very busy with several things.

First, it’s about software releases. VoipNow 2 is in a state when technically it can be released in the beta stage. We will do this in the next days, but first we try to solve all issues that resulted from the automatic tests. This will take maybe two weeks more. We also have some new and not so major releases that we must close, which involve a lot of work.

We first thought about a VoIP control panel for providers about two years ago. Everything started when we were contracted by one of our clients to implement a VoIP integration. Our client, a medium sized hosting company, wanted to expand its product line. They had requests for VoIP services from some of their clients and offering business communication services sounded like a very good business decision. After a lot of discussions with many companies, they were not able to find a solution to match their needs. Our customer didn’t want to come up with something extraordinary. They already had a successful business and they were not tempted to start a new business just to have problems.

After around a month of analysis, it was pretty clear that we must build a solution from scratch. We gather the requirements and come up with a proposal. Unfortunately the costs were too high for our client budget, and we had to drop the project.

In January 2005, we ran a project contest in our company. Basically everyone was able to register a project idea and the best two projects would have been presented to our investors. This would have been a very good opportunity to get the necessary founding. I entered the contest with a VoIP control panel for ISP/HSP. I had a lot of ideas for such a project, and it would have been quite fun to develop the first product of this kind. Some may not agree with the first project declaration. The truth is that I investigated all solutions on the market (and I still do this). Most of them are fundamentally wrong from the software engineering perspective. If someone is really interested I can detail why, but I guess that you must be a developer to see behind the marketing bullshit. An experienced engineer can only install the product and take a look to its architecture. And I did this with many products. I lost a lot of precious hours, but I was able to understand the market.

In our internal contest entered fourteen projects, most of them very interesting and with a lot of potential. I was very excited when I heard that our project won the first place and we will get the founding to make it real. This happened in March 2005. I gathered our team and informed them that we are going to start and bring to live the VoIP project. The development was happy and eager to start working to something new, where they could express themselves and innovate. I was also anxious to use our experience in server software in the new product design.

We started to refine requirements. This was pretty scary, because there were quite a lot. Soon it was obvious that the translation of these requirements into reality will be a challenge. In about two months, we had the requirements list approved, and we started to write the project specifications that addressed all the requirements. We adopted an iterative development lifecycle for the first version of the product. The project High Level Design was extremely difficult to define. During the first three months we realized better the amount of innovation present in the project and how different our product will be of what have been already done by other companies. We did not find many ideas on the market that could have been used ‘as is’. I am a perfectionist and all my colleagues have high standards. Many times we had to modify projects with poor design. The client comes with the code and we can not say no. But in the end a lot of projects are redesigned as this more cost efficient. We knew best what would happen if the project was not designed correctly. We knew that we will develop on the VoipNow the foundation for many years of development, so we proceeded with extreme care during the architecture design steps. BTW, I am sick of companies that announce on every new version a “product redesign”. And they are quite proud of this! Why redesign something if it has been correctly designed the first time? 🙂

I would love to detail more on the first months in the 4PSA VoipNow life, but I am afraid that no one will read on :). A common mistake made by many programmers is that they go into coding very fast. Many companies lack software engineering techniques and make this mistake on first projects. When the project costs increase, when they realize that developers do no longer understand the code, and if the company survives, they start to invest in engineering. It’s sad, but this is the real life scenario.

Well, after about three months we completed the design, the prototype was ready and everything was much clearer. It was obvious that the project presents many risks, and strategies were developed to address these risks. When everything was clear for the team and the initial training was completed, the programming of the first iteration was ready to start.

Although we are experienced developers, programming was not trivial. The configuration items were identified and kept under control. The project is highly modularized, which allows interventions without affecting other components. The most important components are the PHP interface, the C control binaries, the Asterisk applications and the Asterisk patches. The project is based on the Rack-Soft framework, a framework designed to increase the development performance, to address cross platform compatibility issues and to increase reliability. We use two frameworks for PHP and C, and both are in continuous development. This common framework allows us to port changes to active projects quite easily, to control problems and to standardize most operations.

In my next blog post I will tell you more about the product architecture and programming issue. I really don’t know what you want to find more, so please do not forget to send me your suggestions for the next post. Oh, do not hesitate to check the forum at https://forum.4psa.com

First, some background information about me. I started playing with computers eighteen years ago, when I was able to touch one for the first time. It was an IBM PC clone and at that time it looked state of the art. I didn’t like games very much, especially because they seemed to lack interaction; most games available then were quite predictable. Writing a game was a source of fun for many computer enthusiasts. From the beginning I wanted to learn more about the computer internals; I was not scared of the complexity of the machine. I started to dig in the operating system and in the various utils and programming tools available at that time. I started with small tweaks and programming stuff, but back then I was not satisfied about my progress, which was quite slow due to the lack of information sources. Now I believe that it was a good thing because I had to learn a lot to discover most of the things.

I do not remember exactly when I installed Linux for the first time, but I think that it was in 1993. I do remember that I installed Slackware :). At almost the same time I discovered Internet also, due to a university program. The most interesting thing about Linux was the fact that I was able to read the code and learn faster. Things that took ages to debug were much faster with Linux. I remember that I was not very excited about the code quality. A lot of code looked really naïve, but it was wonderful that I could change and improve. At that time the communities were much smaller and the access to the community itself was quite difficult due to the lack of Internet access. Access to local communities was done using the BBS (Bulletin Board Systems).

I remember the Windows 95 release; I liked a lot of interface things, but I was disappointed that it was DOS dependant. After I met Unix and then Linux, I could not make peace with DOS.

Interesting enough, at that time I did not realize that Linux will be used by so many people, that it will be loved and hated, used and forbidden.

Open Source now

Why such a long introduction? I don’t like long introductions, but history is important. In my job I have to answer to a lot of questions daily and this is not very hard. The toughest questions are the ones asked by the strongest competitor, myself. One of the most interesting questions is:

“Why is not Open Source accepted faster?”

This question is strongly related to other questions:

“Are Open Source programs better from the quality perspective?”

“Are Open Source programs more economically viable?”

“Is Open Source the winning choice for companies?”

I think that many people ask this and many more answer to similar questions, but I discovered that only a few answers are objective. People who know a lot about Linux do not know much about Windows, Windows experts haven’t ever installed Linux and so. I do not claim that I am 100% objective, but I try to be fair as I know both parts quite well, although Linux is my native country.

In order to answer to my primary question, I will start with the related questions:

Are Open Source programs better from the quality perspective?

Fact: Most people accept that an open source code is better for flaws detection because more brains read the code.

Life: This does not automatically generate a better quality.

In order for a flaw to be corrected:

1. Someone must be skilled enough to detect it.
2. That person or someone else must write a patch for it.
3. The project maintainer must get the patch into the main code.

In order for steps 1 and 2 to happen the project must be quite popular and in order for step 3 to complete the quality cycle the project must be alive, with a dedicated maintainer. But this might not happen. The nice thing is that the Open Source project can be easily forked if the maintainer is no longer available. But this is usually done only with interesting projects with a large
user base.

Fact: Most bug reports in the open source are behavior based, not code based.

Life: So it does not really matter from the bug reporter perspective if the code is open or closed.

Fact: The maintainer is both the developer and the QA department.

Life: This does not improve the software quality, it defeats basic software engineering principles.

Defects are directly related to the number of code lines, so it’s wrong to say about a small project with a few defects that it’s high quality. Usually large Open Source projects are good quality because they have enough people to handle various aspects of the software lifecycle. The risk is lower because the project does not depend to a single person.

Fact: Founding is important.

Life: Most Open Source projects are not founded, but developers have to live and to go to work. Writing code at 1:00AM might not be the best thing from the quality perspective. A loving wife or a baby can easily get the developer and obviously the project out of the scene.

Fact: Open Source developers are not project managers, although some of them are trained in this perspective.

Life: A lot of people say that the quality of Open Source is superior because they do not experience the commercial programs release stress. I strongly disagree. A software engineered project, open source or commercial, should not face timing issues. If it does, in most cases management sucks.

Fact: Software without management will eventually fail.

Life: When? This is a matter of time and developer resistance. The best software developers I met lack managerial skills and they do not want to improve this aspect. Why? This is still a mystery to me, although I understand each one from the personal perspective.

Fact: Foundations were created to help small, interesting projects to grow. They offer managerial and legal assistance as well as the proper founding.

Life: Unfortunately everything is a matter of money and only very few benefit…

Conclusions

Large Open Source projects with more developers, well founded and managed have a lot of chances to produce high quality code.
Small projects might produce high quality code, but the situation can easily change as new people join the team.

Overall, there are no important quality differences between engineered commercial programs and engineered Open Source software. Unfortunately very few projects are really engineered (commercial or Open Source).

Are Open Source programs more economically viable?

This is a tricky question. Software is economically viable if it does what the customer wants it to do. A software product lifecycle is complex. Microsoft for example advertised the fact that the support costs for Linux are higher than the Windows ones even though the Linux initial costs are low.

I do not argue this, but there is something that must be considered. A ‘set and forget’ system does not bring the economical happiness to the software manufacturer. In fact it’s very dangerous to produce such a system; customers will forget about it and obviously will forget about the provider. No company would want this, that’s why we have a new software release every several months. Server software and MP3 players have now comparable release schedules.

The Open Source software can create administration problems ONLY if its implementation is not correctly analyzed, planed, and deployed. Most managers are tricked and skip many phases because they see such an implementation as a low investment compared with commercial software purchases that must be planned and budgeted.

You cannot use 100% commercial software or 100% Open Source. The ideal situation is where you use commercial software and services for the administration of the Open Source. This does not create vendor dependency and increases the investment case because you buy a solution, with support and updates.

Is Open Source the winning choice for companies?

Every day the small differences between Linux distributions make me nervous. I think that this is one of the ugliest things in Open Source, the lack of standards. Things like namespaces, directories, and configuration files are not easy to change, but they are a very stressing and time consuming task. Most administrators are frustrated that they have to search for a RPM package that has another
name in the new release or that they have to spend hours to upgrade an old server.

This is one of the reasons why many companies are prudent in embracing the Open Source solutions. Companies like Redhat with Redhat Enterprise Linux or Novell with Suse Enterprise Linux do a very good job in ‘converting’ Open Source software to enterprise software. Many people think that this is an unfair way of making money. The truth is that Open Source needs this to evolve and
these companies do not have an easy job. They support Open Source and increase the respect at the Enterprise level.

With proper management Open Source is the perfect choice for enterprise computing.
There are companies that sell it and there are buyers for it.

I do not pretend that I answered the original question, but I shared some of my views regarding Open Source. I wrote this in a weekend after several weeks of interesting discussions with a lot of people involved in Open Source and software development. For the moment I am a little busy, but I promise the second part as soon as I will have a free day.