OSS in a Software Development Firm

How one company is making the move to OSS software for their computing needs.

I have been using Linux as my home operating system of choice for several years. I have used various open-source projects to do practically everything involved in hosting Web sites and databases and serving up e-mail. All of this has been done as a hobby, and I often longed for the day when I would be able to bring open source into the office.

I work for a software development company as a programmer/analyst, developing administrative software for higher education. Our original software was written in COBOL to be run on an HP e3000 using the MPE operating system. A few years back we recognized that we needed to bring our software into the 21st century, so we chose Delphi to migrate our legacy applications to the Windows platform.

Before we were able to migrate our application suite, HP announced the demise of the HP e3000 and the MPE operating system. This left us in a bit of a predicament. At the same time, it presented a great opportunity for the company to take a step back and evaluate where we were going and how exactly we were planning on getting there. We listened to feedback from our customers, talked to our technical gurus and decided to stop the conversion to the Windows platform and investigate other options. Java was mentioned, and we began developing a proof of concept.

During the development of the proof of concept is when the first open-source products started creeping under the door. We started using Eclipse as the IDE. Eclipse was quite popular in the Java world and it was being developed actively. In addition, the support of the user groups and, of course, Google was tremendous. Although many of the developers chose to use Eclipse, others tried NetBeans, EditPlus and various other development environments.

Also during the proof of concept, a product by the name of PerCOBOL was mentioned. PerCOBOL is a product from LegacyJ to convert COBOL to Java. The PerCOBOL IDE was based on Eclipse. By this time we had finished the Java proof of concept, and the response from the higher-ups was positive. We now had to develop another proof of concept, however, using the PerCOBOL product to convert one of our more complicated tasks.

While developing the PerCOBOL proof of concept, it became apparent that we needed to standardize our development tools. One of the major indicators of this was the use of CVS. All of the various IDEs being used at the office handled CVS integration differently. Training the developers on the use of CVS was cumbersome at best. With the decision to use PerCOBOL, we chose to standardize on Eclipse.

I snuck CVS in above because it was the major factor in our decision to standardize on an IDE. However, it was the wide support for CVS of all the major IDEs that allowed us to choose other open-source projects.

Aiming to be as platform independent as possible, we chose to support any J2EE-compliant application server. This decision opened the doors for JBoss and Tomcat. The fact that Jboss recently received the great funding it did gave some validity to our decision to support it. Tomcat was a no-brainer for development reasons: it is fast and lightweight and has a small footprint.

Another no-brainer was Ant. Ant allowed us to streamline the process of compiling and deploying the applications being developed. This also increased the production of code because all of the developers need not know the particulars of deploying on the various application servers. We developed build files that could be used with the each of the application servers. We just as easily could have created one build file with various build targets corresponding to the application servers, but we thought it would be easier to understand and maintain several files directly relating to an application server.

With the proof of concept for both the Java project and the PerCOBOL piece complete and receiving rave reviews, we really began the process of developing our next generation software. Or so we thought.

Our development practices were not the most organized and were not even close to being standardized prior to our Java conversion. The developer wrote the code, tested the functionality of the code and placed the code into production, nothing more to it. Each developer had a specific area of expertise in the huge system we developed. Some worked on a financial aid piece, other worked on the housing piece and still others worked on the registration piece, to name only a few.

We now were faced with an opportunity to cross-train ourselves. We decided to convert the system one module at a time, starting with financial aid. The COBOL programs obviously didn't fit into one Java class. It was at this time that I heard about Struts. Struts is another open-source project that allows for the separation of the business logic from the database and presentation layers. It's more formally known as MVC, or Model/Viewer/Controller.

Around the time that Struts was introduced, after some training presented by Marty Hall, I was presented with an exciting opportunity. Everyone in the office had been listening to me preach about the greatness of Linux and the numerous distributions I use. But now, developing with Java, I could start using Linux as my development operating system. In fact, doing so was encouraged for testing purposes to allow us to be platform independent.

We soon discovered that training our current developers was not going to cut it. Even though we had very talented developers, we needed to hire an expert Java developer to be used shamelessly as a resource by our current team. The new developer was not only a Java expert but also an open-source advocate and a proponent of Linux. Presented with his new laptop he proceeded to wipe it clean, put on a fresh install of Fedora and away he went.

Using Ant on a developer's machine worked well, but in our testing environment, it was cumbersome and time-consuming to grab all the updates from CVS, build each piece involved, notify the developer of any given piece that failed and, finally, deploy on the testing application server. Enter CruiseControl. CruiseControl automates the integration of changes made in CVS as well as the build portion. CruiseControl has saved me, personally, hours of work. The CruiseControl system notifies the developer of any piece of code they have checked in that fails to compile, gives a report of all the pieces updated and sends out an e-mail to all the developers notifying them that a new build is available. With CruiseControl we quickly can locate a problem with new code that has been introduced and either roll back the previously working code or apply patches to the buggy code. Having set our CruiseControl installation to check for updates in CVS every five minutes, we find small problems before they became large problems.

Another feature of CruiseControl is the ability to run JUnit tests and display the results. As I mentioned before, our software development processes up to this point were informal. With CruiseControl and JUnit we could write test cases and have them placed directly into our continuous integration process. So, not only did we have our changes available with any compilation problems found immediately, we also were able to unit-test our code and quickly remedy problems such as database leaks.

With our development processes down and unit-tested code available, it became time to test the functionality of the applications being produced. In the beginning we combined the project management and the testing into one Excel spreadsheet. I am certain you can understand the kind of nightmares this caused. At that time I and another developer gave the suggestion that I install Bugzilla on one of the older desktops. Bugzilla is not necessarily the most attractive bug-tracking software, but it certainly beats using a spreadsheet, freeing us from the hell of someone going to lunch and locking their desktop with the spreadsheet open. Bugzilla has more than enough features for our needs.

The latest introduction of open-source software has been phpCollab. As I previously mentioned, our project management consisted of one part spreadsheet and several parts frustrated developers. phpCollab has allowed us to divide our applications into smaller modules. For example, for those applications requiring user input, we divide the project into three to correspond to the specific piece in MVC standard.

Open-source software has been an aide to our software development firm and as I sit here, writing this article in OpenOffice.org, I can see the use of OSS only growing. When I discussed writing this article with our president, he was fairly surprised by the amount of open-source software in our company. He knew the names of the projects but was not aware that they were open-source. We even joked about putting Linux on his laptop. Some colleagues have expressed interest in installing Linux on their development machines in a dual-boot scenario. Other colleagues use OSS projects on their Windows machines to test user interfaces, validate XML and test office compatibility. We have managed to bring numerous OSS projects into everyone's vocabulary and have proven the reliability and usefulness of OSS in the corporate environment.

Daniel McCarthy is a programmer/analyst for the Computing Options Company.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: OSS in a Software Development Firm

Anonymous's picture

Don't forget to contribute to some of the projects!

Re: OSS in a Software Development Firm

Karl's picture

This is an excellent article! It shows that, with an open mind, open source tools and some persistance, that Open Source Does Work and Wins, again!!!

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState