What ProcessMaker developers will do for meat pies

By | July 19, 2011 | Development Plans, ProcessMaker

Programmers are famous for their predilection for certain foods. It is claimed that the best way to get a programmers to write code is to offer them all the pizza and Mountain Dew they can ingest in the wee hours of the night. Theo de Raadt, the infamous developer of OpenBSD, solicits grateful users of his operating system to send pizza deliveries to his house. The “hackers” at MIT during the 60s and 70s who created the Incompatible Time-Sharing (ITS) operating system and the culture of free software were renowned for not only for their programming skill, but also their tastes in Chinese food. They were known to carry around Chinese dictionaries just so they could read the menus at their favorite restaurants and order the secret dishes which weren’t on the ordinary menu in English.

Two salteñas The ProcessMaker developers also have their favorite food. It comes in the form of a baked meat pie, called a “salteña”, which is a specialty found only in Bolivia. Salteñas are made of beef or chicken in a sweet and spicy sauce, enwrapped in a dense crust to retain all the delicious contents when baked. Each bite is accompanied by an explosion of juice. It takes special skill to eat a salteña without having the the succulent juice running all over your shirt. The ProcessMaker developers have mastered the fine art of first shaking the salteña to release all the juice bits inside, then nibbling a tiny hole at one end and sucking out the juicy contents before they dribble into their laps.

It can be hard to convince programmers to change their operating system, especially when they have spent years learning all the tricks with a particular set of tools. Relearning a new set of programming tools can take weeks and programmer are often reluctant to change familiar tools which already work. Nonetheless, the ProcessMaker development team realized that their old development tools were not adequate for the new tasks confronting them. After going through the painful process of developing version 2 of ProcessMaker, with many separate branches of code and a growing programming staff, Fernando Ontiveros, the head of ProcessMaker development team, realized that the developers needed a new code management system.

ProcessMaker’s code was being managed with Subversion, a concurrent versioning system, but the developers needed greater flexibility to work on separate code branches on their individual machines and more precise code management to merge those branches together and cherry pick bits of code when packaging a new release. Alexandre Rosenfeld, a Brazilian developer who had worked on a number of GNOME projects in the past, was also frustrated by the limitations of Subversion. He had used a number of distributed version control systems (DVCS), such as Mercurial, git and Bazaar and knew that DVCS could substantially improve ProcessMaker’s development. He suggested that ProcessMaker switch from Subversion to git, which was his favorite DVCS tool.

Fernando Ontiveros liked the idea of using git, but it posed a problem. Git does not work well on Windows, which almost all the developers used for their development work. While ProcessMaker developers were hosting their code on CentOS servers, they were accustomed to writing that code using tools which only run in Windows. After years of using UEStudio in Windows, it would be difficult to learn a new IDE that ran in Linux. The question was how to convince the rest of the developers to switch to Linux and git. Fernando decided to appeal to their gastronomic desires with a delectable bribe. He offered to buy salteñas for the entire development team if they would install Linux on their personal machines and started using git.

With the pleasures of the palate in mind, the developers applied themselves to the task with gusto. Three of the developers were already using Ubuntu, so the rest of the developers decided to switch to that distribution of Linux as well. Git has a much steeper learning curve than Subversion. Even after a training session to use git, it still took quite a while to configure git on each developer’s machine and learn how to use it. After creating local repositories on their personal machines, many of the developers corrupted their repositories with their first commit and they had to issue the “git pull –rebase” command to straighten out the mess. Fernando recalls that one developer’s repository became so corrupted that his commits made it impossible for others to continue working, and it took 3 developers half an hour to figure out how to undo the corrupted commit with a “git commit –amend” command. Erik Amaru, a long-time ProcessMaker developer, commented, “At first is was a bit traumatic, but now we have become accustomed to git”.

Just as big of a challenge was finding a new code editor to replace UEStudio. The developers tried out complete development environments like NetBeans and Eclipse, but many of the developers complained that these Java applications were too slow. Some have decided to use GNOME’s basic text editor, GEdit, for their coding. Although it does not offer the conveniences of an fully integrated development environment with function and class lookup, GEdit does support code highlighting and it’s speedy and light enough to run well on any machine. Nobody has decided to switch to the traditional terminal-based text editors like emacs and vim, but the developers have been trying out a number of different text editors, so now the ProcessMaker code is being worked on with a plethora of text editors. The important thing is that all the code is being produced in UTF-8 character encoding, so there can be no character confusion, no matter which editor is being used.

At the same time that the development team was transitioning to Linux for their personal machines, the support department, was making a similar transition, but without the tasty incentive of salteñas. Amos Batto in Support had long used Debian, but his efforts at evangelizing software freedom had fallen on deaf ears among his peers. Although the Support department had always run both Linux and Windows (and even BSD occasionally) in virtual machines so they can offer support to clients on multiple operating systems, most of the Support team used Windows for their base operating system. The Support department was a decidedly Windows shop, until Marco Antonio Mamani decided to switch to Ubuntu simply to learn Linux better. All the new employees in Support decided to use Ubuntu as well, partially to keep their Linux skills sharp, since most run Windows at home.

Windows enthusiasts, however, should not despair. The ProcessMaker development team remains committed to developing a multi-platform application which runs just as well in Windows as Linux/UNIX. In fact, to ensure that ProcessMaker runs well on all the supported operating systems, the Quality Assurance team has begun a rigorous regime to test all new releases on 12 different operating systems. With most of the Sales, Quality Assurance, and Projects departments still using Windows on their personal machines, ProcessMaker is going to be put through its paces in a whole variety of operating systems. Just in case anyone is too worried about the spread of the tuxedo-sporting penguin, Fernando Ontiveros, the head of development, still writes his code on a Windows box. Although he bought salteñas for everyone else in development, apparently nobody offered to buy him a salteña to switch to Linux!