The case for using open source developer tools is more strategically related to cost savings than the strategy of using open source software for ease of customizations. In most cases, developers use the tools or additional plug-ins out of box and don't customize them. When they do customize a tool for additional functionality, most submit it back to the open source community. Often times, they will add new functionality in the form of a plug-in for ease of use or management. Plug-ins allow more flexibility so consumers can choose what functionality to load and what not to load.
At Novell, hundreds of developers are writing code. Although Novell IS&T is primarily a Java shop, we use a vast array of languages in the various departments across Novell. In this case study, We'll help you explore common tools used in our IS&T engineering tools team; however, the same tools are applicable for any type of developer or language of choice and widely used in most areas of Novell. Also keep in mind as you read this article that there are hundreds of open source tools out there depending on what your needs are. We'll only introduce you to a few of our favorites.
> Eclipse (eclipse.org)
You can also find plug-ins for Eclipse to code in most languages. These plug-ins offer syntax highlighting and checking. These plug-ins save hours in productivity increases for developers and assist in producing quality code. You can find a vast amount of information on the Eclipse project Web site regarding the project plan, build schedule, bugs, coding standards, API, available plugins, and about anything else you'd want to know. This project community is very active and had made great progress in maturing this open source tool.
You can download the latest version of Eclipse (version 3.21) from download.eclipse.org. In addition, if you load the Callisto discovery site plug-in, it will load most everything you commonly need. Callisto is a suite of development plug-ins downloadable from ftp.osuosl.org/pub/eclipse/callisto/releases/. (See Figure 1.)
In the past, we used a proprietary development platform that was purchased for developers. This tool was very expensive and we had to buy a license for each developer. The maintenance fees alone were US$1,500 per individual per year. This was an excellent package of software and development libraries and suited the development efforts at the time.
As costs become prohibitive, we looked for other options and started making the move to Eclipse. In the early days of Eclipse when it was not as mature, developers yearned for some of the features and functionality of the proprietary software they were used to; however; now that is no longer the case as Eclipse has matured to meet the needs and expectations. One of the biggest turning points for the developers in teams in our area was the release of the Web Tools Project (WTP). This suite of plug-ins allowed the developers to have most of the functionality they were use to and really leveraged them into mainstream development.
Let's highlight a number of plug-ins that are commonly used here at Novell for development work.
With this Web tool kit, Eclipse is now mature enough to handle most Web application development and debugging. Many projects out there now are very helpful when developing, and one of our new favorites for the new AJAX framework is eclipse.org/atf. This is an additional plug-in that lets you create AJAX applications in Eclipse. There are also other projects for creating tools for AJAX being used inside of Eclipse.
Another plug-in the developers who code in Perl like to use in Eclipse that helps format and debug Perl scripts is called E-P-I-C and can be found at e-p-i-c.sf.net.
If you are considering setting up Eclipse in your organization, set up a Wiki to allow your group to share information and build a help reference. Usually there is no out of the box install that installs and sets up all of the plug-ins you might want to use in your organization. Creating a Wiki up front will save you time and headaches in the long run. There can be a lengthy and often detailed process to get these open source tools configured the way you want them.
You might find the documentation is not as current or as thorough as you'd like. The Wiki will be a great resource when your new developers come on line with these tools. It will save hours in time and frustration. Another benefit in having all of your development team set up the same way is it prevents glitches when you share and reuse code. It also helps in familiarity when reviewing code. If you don't have Wiki software, check out mediawiki.org. (See Figure 3 and Figure 4.)
Another must-have plug-in for our developers is the Subclipse plug-in found at subclipse.tigris.org Subclipse lets you manage your Subversion work area, such as commits, updates and diffs, from inside Eclipse.
Subversion: subversion.tigris.org Subversion is a version control system that is familiar to CVS users but fixes a lot of the architectural issues within CVS. (CVS is another version control system that's been around for quite a few years.)
Below are some of the main features of Subversion. For a detailed set of features, visit their Web site at subversion.tigris.org.
Note: The following quotes are taken from subversion.tigris.org.
> Atomic Commits
"No part of a commit takes effect until the entire commit has succeeded." Therefore, if one person is checking in while another is retrieving updates, the one retrieving will not receive a partial commit. This feature also makes it trivial to revert (undo) a commit, no matter how many files were in the commit.
> Version-controlled Directories
One of the most frustrating things about CVS is that directories are not under version control. Because Subversion maintains the revision history of directories, every rename, move, copy, add and delete is tracked. So, for example, if you check out an old revision of a repository, it's guaranteed to look exactly the same as it did when that revision was checked in. This is true even if the directory structure of the repository has changed dramatically over time. With CVS, such reproducibility of old revisions is challenging.
> Branching and Tagging
When you create a tag or branch in Subversion, it takes a small, constant amount of time. This feature is another advantage over CVS, especially for large repositories.
"In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place.... Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions."
One of the biggest wins for us is the ease with which we can manage user accounts and repositories. We use Subversion's mod_dav_svn module for Apache, which allows us to use the power of Apache's configuration, authentication, authorization and access control features. In particular, we use Apache's mod_auth_ldap to implement our access control policies. When a user accesses our Subversion server, the server uses mod_auth_ldap to make authentication and authorization decisions by connecting to a Novell eDirectory server via the ldap protocol. The system is so automated that we can manage more than 300 Subversion repositories and almost 700 users on the same server without any intervention from the IT department.
The following is a sample Apache configuration file for a single repository. It might give you some ideas for your own implementaion. Each repository has a configuration file very much like this one:
< Location /svn/bri>
AuthName < realm>
ldaps://< servername >/o=< org>?cn?sub?(< filter>)
< LimitExcept GET PROPFIND OPTIONS REPORT>
Require group cn=< group>,o=< org>
The following is information about our Subversion/Apache server:
OS: SUSE Linux Enterprise Server 9 SP3
CPU: 2 Intel(R) Xeon(TM) at 3.60GHz
Memory: 6 GB
Subversion repository type: fsfs
Apache/Subversion Uptime: 186 days
Apache Parent Server Generation: 296
Total accesses: 61,362,983
Subversion has been invaluable and is a real productivity enhancer. The community for this tool is also very active and growing all the time.
Because many of these tools have reached a high enough threshold of maturity in their life cycle, these open source developer tools are viable options for you if you're interested in saving money to your bottom line.
Log: Allows you to see revision history. (See Figure 6.) Every revision is tracked with a unique number. You have several choices for each revision:
- revision x: see a summary of the revision itself
- view: view this revision of the file with syntax highlighting
- download: download the file to your computer
- as text: view the file with no syntax highlighting
- annotated: view the file with annotations (more on that below)
- select for diffs: select this revision so you can diff it with another revision
- diff to previous: view a side-by-side color-coded diff between this revision and the previous revision
Annotate: Shows the entire revision of the file and includes author and revision information for each change. (See Figure 7.) If you click on a revision number, it shows you a side-by-side color-coded diff between that revision and the previous one.
Diff: Allows you to see a side-by-side color-coded view of the differences between two revisions.
Markup: Shows this revision of the file with color-coded syntax highlighting.
ViewVC is simple to use, yet powerful and full-featured. You won't go wrong having this tool in your tool chest.
I'll quickly mention a couple of other tools that are worth looking into:
Irfanview irfanview.com This is one of my favorite open source graphic or photo view tools that is very popular.
GAIM gaim.sourceforge.net A multi-protocol instant messaging (IM) client. This is helpful for collaboration (or chatting) with other developers while working and needing quick communication no matter the platform or physical location.
This case study just skims the surface of all of the many possibilities of developer tools out there. We've seen an incredible increase in the offerings of open source developer tools and many are feature rich and becoming widely accepted as a first choice for developers. We use many of these tools and thus save thousands of dollars to Novell's bottom line, all while not decreasing productivity by using open source tools.
Because many of these tools have reached a high enough threshold of maturity in their life cycle, these open source developer tools are viable options for you if you're interested in saving money to your bottom line. Take the plunge and give one of these a try, or look for something more suited to the type of development work you do. You won't be disappointed. Even better, if you end up developing new functionality with them, give back to the open source community for all of us to benefit as well.