Q: Why is open source good for government?
A: There are six key reasons why governments are moving to open source. They include:
- Security. Open source is statistically shown to increase security in most implementations. This is particularly relevant for intelligence agencies that focus on security.
- Procurement time. Government procurements can take up to three years. By moving to open source, agencies can download and deploy software immediately and then go through procurement for support rather than acquisition.
- No vendor lock-in or lock-out. Because open source is in the public domain, support is available from multiple vendors. For Solaris, users can get support from HP, Dell, IBM, Sun, Intel, AMD, and a host of others.The same goes for Linux and other open source environments. Additionally, because the APIs are open sourced, they're easier to reverse-engineer to avoid lockout.
- Reduced cost. Open source support contracts are usually significantly less expensive than proprietary contracts because there is competition. That's not the case when the code isn't publicly available. We often say that open source gives 90% of the functionality at 10% of the cost. This results in billions of dollars of savings for governments.
- Increased quality. There are fewer patch releases with open source, in part because open source code goes through more reviews. During the release process, the code is reviewed by the community, which can be ruthless in its scrutiny. The code then goes through integration review, indemnification review if supported by a vendor, and quality control. That adds up to three times more quality controls than most proprietary products.
- Collaborative environment. By engaging with open source, governments can inject unique requirements into the community without having to go through a vendor. This is a huge boon for governments because in the past, vendors often couldn't justify doing unique requirements for a limited number of government seats.
Q: To what extent are governments around the world adopting open source solutions?
A: About 87% of governments and businesses globally have adopted open source solutions for large-scale mission critical applications. As a whole, governments were rather slow to adopt the Internet and they've been the same way with open source. But over the last five to six years, that has changed. They now acknowledge that this is useful in mission-critical environments.
In terms of who is in the forefront, Brazil is clearly a leader. China, India and the U.K. also have strong open source policies. The Netherlands, Germany and Russia are also moving heavily toward open source. The United States has lagged somewhat, much as we did with adoption of wireless and mobile communications, but it's becoming much more prevalent in the U.S. government under the Obama administration.
Every large company and government should have an open source policy that acknowledges its existence and determines how to manage it. There are good and bad things about open source. If you don't manage it well, a slew of problems can result.
Q: How has Sun worked with the Obama administration to evangelize open source?
A: We've worked closely at both the administrative and congressional levels to get policies in place to allow organizations to adopt and manage open source. If you mismanage open source, you'll have a mess, and if you manage it well, you can get tremendous value. We've seen great adoption with the national information health care system. We've also seen additions to the defense appropriations and health care bills where they specify the use of open source for security and privacy reasons along with cost reduction.
Entities should evaluate open source alternatives just as they evaluate alternatives for any type of acquisition. It should not be mandatory however. It needs to be evaluated on an equal basis for its own features and capabilities. If you want open competition, you don't want open source to be excluded, but you don't want proprietary offerings to be excluded either. You want competition based on merit. Evaluate your open source versus proprietary products based on security advantages, cost advantages and deployment advantages along with the risks. If you're using an open source product that doesn't have strong community or vendor support behind it, you're running risk. The same is true for a small, proprietary company that could go out of business. At least open source goes into the public domain, so other companies can pick it up.
Q: How does open source technology address security?
A: Security is a strong area for open source. One issue we have today is that all software products are written globally — India, China, Russia — all over. This allows people to inject things into the code. If it's proprietary, you can't see it. If it's open sourced, you can. By making it open source, it's harder for people with malicious intent to inject things into the product. Many proprietary vendors will say they have their security experts review the code. But we're talking millions and millions of lines of code — 15 to 30 million in Windows alone. There's no way a small panel of experts can review that much code. But by exposing it to the 900,000 people in the open source community, you have many eyes scrutinizing it along with those security experts, which tends to surface security issues before they're exploited. Openness forces better security. Additionally, because open source vendors know that the algorithms they use to secure their code are going to be public, they make them very robust.
Q: How does open source address cost savings?
A: Firstly, via speed of procurement. With open source, you can go to a certified source, pull down the source code, and immediately start deploying before you get support or licensing in place. That speed saves money. Then, you save money when you negotiate the support cost because the code is open and there is competition on the support. You don't have that with proprietary products because there is only one vendor with access to the code. You'll often see savings of as much as 90% over a proprietary product. Just make sure that what you buy offers things like indemnification. Depending on what you pay, you can often get 24/7 global support as well.
Q: What should a government or enterprise look for when evaluating open source?
A: Look for a solution with an active community. Some open source products are science projects. Look for a vendor or multiple commercial vendors who stand behind their product so that you have one throat to choke if something goes wrong. Look for vendors who provide indemnification so that you know from an intellectual property perspective that you won't be at risk. Also, understand the licensing. All open source products have to be under an Open Source Initiative (OSI) approved license. Check out the OSI website where there are about 40 different licenses. Make sure you understand the three different families of licenses and how they affect how you resell or redistribute what you build in open source. Another area to check is drivers. Many times, proprietary vendors will pay hardware manufacturers to initiate drivers as the product comes out, whereas the open source community generally lags on drivers. Understand what is available with regard to your time frames.
Q: When evaluating open source products, you'll often see two versions. Why is that?
A: Generally, what you'll see is a community version and an enterprise version. Sun has Solaris and OpenSolaris. There's a community MySQL and an enterprise MySQL. The community versions are wild and always changing because the community is always contributing to them. You can certainly run your environments on those community versions, but there is risk because they are in constant flux. IT organizations don't like flux for obvious reasons. As a commercial vendor, we create an indemnified, supportable open version that we sell an enterprise license for. Depending upon what you're doing, it's a good idea to understand both. In some cases, you'll want to be engaged in the community in order to inject your features and requirements into the product. But when you're ready to deploy on a large scale, you'll probably want an enterprise version.
Source: Sun.com
Bejegyzések
