About
Open Source
News
Applications
Projects
Licenses
Contribute
Mailing List
FAQ

Frequently Asked Questions

This question is more appropriately asked of all bridge engineering software. How can an end user be sure that any engineering software package has undergone adequate quality assurance testing? Because the vendor says so?! Without industry accepted QA/QC standards, certification requirements, and compliance checking the consumer will have a difficult time knowing if a bridge engineering software package has been adequately tested. Compare this with software developed for commercial airliners. Before a piece of avionics software makes its way onto an airplane, strict development and testing procedures must be followed by certified developers. Then, the software must be certified by the FAA. The bridge engineering community currently does not strive for this level of reliability (but probably should).

However, this concern is understood: If anyone can modify the source code, how does the consumer know if he is getting a “good” version or a “bad” version. There are two safeguards in place to address this issue. First, under the terms of the Alternate Route Open Source License, if someone distributes a modified version of copyrighted software this derivative work must carry a name that distinguishes itself from the original work. If this is not done, the distributor is in violation of the agreement and the copyright holder may take legal action to halt the distribution of the software. Secondly, engineers who choose to use computer tools to perform calculations have a responsibility to be informed consumers. If an engineer is skeptical about the quality of John Doe’s distribution of a piece of software, he shouldn’t use it. This is true regardless of whether the software is open source or closed source.

Open source software has two significant advantages over closed source products when it comes to quality. Because the source code is freely available, a knowledgeable engineer can study the implementation and determine if it is adequate. Source code distributions frequently include the developer's test cases. An engineer can even load the software into a debugger and watch every calculation unfold for a particular set of engineering calculations. This is not possible with closed source software. The second advantage is that open source software is continuously subjected to independent peer review from engineers worldwide. This fosters feedback that ultimately results in higher quality software.

Who pays for the development of this software?

When we talk about in-house or jointly developed software produced by DOT's, it is ultimately the taxpayers of the United States of America that finance the development. DOT's produce publicly owned software, and Open Source is the best way to get the maximum benefit for the taxpayer.

On a less abstract level, those that derive value from the software pay for it. To understand this, we must first define value. Software has two forms of economic value. It has market value and use value. Market value is the economic value software has as a saleable commodity. Since the government isn't in the business of selling software, DOT produced software doesn't have market value.

Use value is the economic value you receive from software by using it as a tool. The software has value because you can do something faster or more economically then without it. It is this use value that inspires DOT's to develop in-house software.

Consider AASHTOWare products… AASHTO member States fund the development of this software. They are doing this not to generate profit, but rather to build tools from which they will receive use value. Would AASHTOWare products be less useful if they were distributed with Open Source Licenses? Absolutely not! The need for this software is the same, regardless of how it is licensed. If AASHTOWare were distributed with an Open Source license, would member States stop funding the development? No… if funding were to stop, so would development and the use value of the software would never be realized.

Those getting use value from software are willing to pay for its development. Because use value does not depend on licensing, those deriving benefit should still be willing to pay for it regardless of how it is licensed.

Actually, just the opposite will to occur. Open source promotes software reliability and quality by supporting independent peer review and rapid evolution of source code.

All software has bugs, even software that you rent for thousands of dollars a year. Open source software can obtain a much higher level of quality because of independent peer review. Anyone can dig into open source software and find problems. By reporting problems and solutions to developers, the software only gets better. The more eyes that look at source code, the more shallow problems become.

In addition to higher quality measured by the absence of defects, open source software has the additional characteristic of higher quality measured by robustness. Open source software evolves when real users add the features they need. You don't have to say, "This software would be great if only it did…". You have the freedom to add what ever functionality you like. Again, the software can only get better.

You always have control of the source code for your software. If someone else has a copy of the source code and makes changes to it, it in no way effects your copy.

As a consumer of open source software, you have a level control that you don't get with closed source software. Because you have the freedom to modify source code, you aren't shackled to every decision the developers make. You can adapt the software to meet your needs. You are not at the mercy of unfixed bugs. You can even purchase support and services from anyone you like. You are in complete control from the perspective of both developer and consumer.

This is a problem that has very little to do with Open Source Software. When your DOT enters into an agreement with a consultant, you have two choices: specify which software is to be used or don't specify it. This choice exists with or without Open Source Software.

If you are in the first camp, specifying which software is to be used, continue to do the same as you've always done - specify the software. If you currently require Version 2.5 of XYZ Program, published by your DOT, then continue with that practice. Nothing changes!

If you are in the second camp, you don't specify which software is to be used, then simply continue with that practice. If it is acceptable for a consultant to design bridges with the software of their choice, then it should be acceptable if their choice is a derivative version of your in-house software. Again, nothing changes!

A very common way to get support is to simply ask the developers. While the developers probably don't have a contractual obligation to answer your questions, they usually will. Common courtesy goes a long way when forming a mutually beneficial relationship.

The most common means of receiving free support is mailing lists and news groups. These are the equivalent of bulletin boards where you post questions and knowledgeable users answer them. Mailing lists and news groups rely on peer to peer communications for support. WSDOT currently hosts a mailing list for Alternate Route Project topics.

Open source software offers end users a significant advantage over closed source software when it comes to support. For closed source software, support is provided exclusively by the software vendor. Good or bad, this is all the consumer gets. With open source software, consumers can get support services from anyone they like. Providing a service and support package is probably the oldest and most successful open source business model. Typically, a company will offer a package that consists of a CD containing software and a support and service contract. Since the software can be freely obtained, what the consumer is buying is the service. Now, if the customer is unhappy with the service for any reason, he can choose to purchase it from a different company. This fosters competition amongst service providers and results in high standards for support.

Copyright © 1999-2000, Washington State Department of Transportation