Open-source software (OSS) is computer software for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that meets the Open Source Definition or that is in the public domain.

This permits users to use, change, and improve the software, and to redistribute it in modified or unmodified forms. It is very often developed in a public, collaborative manner. Open-source software is the most prominent example of open-source development and often compared to user-generated content.

 

The term open-source software originated as part of a marketing campaign for free software.

A report by Standish Group states that adoption of open-source software models has resulted in savings of about $60 billion per year to consumers.

Source from http://en.wikipedia.org/wiki/Open_source_software


Read more about open-source software at Open Source Initiative


Small businesses with small budgets can save a lot of money by deploying open source software--at least in theory. The Linux operating system and office productivity software such as Open Office can be downloaded free. That sounds a lot better than paying $200 for each system's OS and $300-500 more for an Office suite.

Also in theory, large companies stand to save even more because they need so many more copies of each software program. Multiply $500 savings per machine by 100 computers and we’re looking at substantial cost savings: $50,000.

But is open source really scalable enough to grow with your company? Let’s look at some of the pros and cons of switching to open source solutions for both small and large companies.

 

The cost factor

We included the caveat that the savings mentioned above are theoretical, because deployment of open source software may carry hidden costs that affect the comparison with commercial software. For example:

  • The learning curve for open source software may be greater, especially for end users who are not "power users." Depending on the particular distribution and the graphical interface, an open source operating system may require more technical skill to master.
  • Administrative overhead may also be greater, as IT professionals are expected to master a command line interface and be proficient in scripting, writing their own device drivers, and so forth.
  • Technical support may not be provided by the vendor, or may cost extra. Of course, there are also commercial distributions of open source products that do include tech support, but their cost is not zero and may even approach or exceed that of proprietary software.

For example, according to the Red Hat web site at http://www.redhat.com/rhel/compare/server/, a per-system annual support subscription for Enterprise Linux AS costs $1,499 (standard) to $2,499 (premium). Thus, in evaluating or planning for an open source deployment, always be sure you’re comparing "apples to apples" by including any additional costs for training, overhead, support, etc.

 

Benefits of Open Source

Cost considerations aside, open source software can provide a number of benefits, especially to technically savvy users. These include:

  • Because the source code is available and the licenses generally allow modification, your in-house programmers can customize it to fit your needs.
  • Another benefit is "security through disclosure"--anyone can examine the source code and discover security flaws, and anyone can write fixes for them; you don’t have to wait for the software vendor to do so.
  • Open source software that has matured and been through the peer-review process continually for years is reliable; as an example, much of the software on which the Internet runs (DNS, Sendmail, Perl, etc.) is open source.
  • Most open source software enjoys a great deal of community support--user groups, web boards, newsgroups, mailing lists, etc. where you can go to ask questions and get help.

Open source advocates tend to "stick together" and share knowledge just as they share the software. However, in some communities you may find that "newbies"--both those who are new to technology and those who are skilled in Windows administration but have little experience with open source--are not particularly warmly welcomed.

In the past, many open source users projected a somewhat elitist attitude and scorned anyone who found recompiling kernels "too difficult" or who wanted an intuitive graphical interface. In recent years, open source advocates have opened up their doors more and started recruiting average users as well as techies, perhaps realizing that the more successful users are when they try open source software, the more widespread and respected open source will become. This has led to the development of much more user-friendly open source programs.

 

Deploying Open Source in the small business environment

The trend toward making things more user-friendly makes it easier to deploy open source in small business environments where you may not have highly skilled full-time IT personnel. However, just because it’s free or low cost doesn’t mean you should treat it more casually than expensive proprietary software. Planning and testing are just as important (and perhaps more so, when dealing with inexperienced users) as with any other software.

Small businesses may find it easier to start with open source servers, sticking with Windows (and/or Macintosh) on the desktop. This avoids the problem of the end-user learning curve, and if you have only a handful of desktops, they are likely to come with an operating system installed. Even if not, the cost difference for desktop operating systems for ten computers, for example, may be less than the cost difference for a single instance of a server OS. You can still save money by using productivity applications such as Open Office that run on Windows.

 

Deploying Open Source in the enterprise

In an enterprise environment, the sheer volume of machines makes any change in operating systems and applications a costly and time consuming undertaking. Whether you’re switching to open source for servers, the desktop, applications, or all of the above, you should first test all of the new software thoroughly in a lab environment and then run a pilot program with one department or group of users before rolling out the change on a large scale.

The best time to make such a change is when you would otherwise be upgrading your current software. For example, if the operating system you’re using is at the end of its support life and you’re about to be forced into upgrading to a new version, that’s the most cost-effective time to make the switch to open source.

 

Other deployment considerations

Switching to open source doesn’t have to mean you’re "out there on your own." Vendors such as Hewlett Packard and IBM offer services to customize and integrate Linux/UNIX software and hardware, perform on-site installation and assist with migration, training and support.

 

Summary

Open source software provides both benefits and challenges to organizations of all sizes. Properly chosen and deployed, open source operating systems and applications can scale to meet almost any need in both the server and desktop space.

 

Source: Written by Deb Shinder of www.techrepublic.com


Google: Open source lets us control our destiny

By utilising open source, Google's Chris DiBona says the company is able to control its own destiny without having issues with vendors or relying on external parties for development and allowing the company to tinker with its own code.

DiBona, Google's open source program manager, gave the opening keynote at the Open Source Developers' Conference 2008 in Sydney today. Builder AU caught up with DiBona after his keynote to discuss why Google uses open source, how the company open sources its software and what it is like to be a comic book character.


How does Google control its destiny with open source?

DiBona: Basically, we use it.

The problem with commercial software is that generally you can't control what you do with it.

There's very specific terms around how you use it, where you use it, how you can ship it or not ship it, how you can use it or not use it on the web -- who you can show a website to.

I'm sure being in Australia that you've seen a website that says: "I'm sorry, you're in Australia, I can't show you that".

Open source software doesn't have that kind of restrictions.

If you're a company, using open source software is a great start for doing what you want with your computer -- and that's what we do with it.

 

As the licence guy for Google, do you spend much time looking at proprietary licences?

Actually I do and it's horrifying to me. Horrifying is probably too strong a word.

Commercial software often has restrictions on it that are very, very difficult to track. Not just user limits or client connection limits, but things like thread limits, or machine/CPU limits, or data storage limitations.

All sorts of things that are very troubling for us.

Because our datacentres are incredibly large, and so having [costs] based on the number of cores that you might run something on is very dangerous for us.

We do have some commercially licensed software, absolutely, but we try to keep that to a minimum.

It's hard to track and it's something that I don't envy commercial organisations on at all.

 

How important do you consider tracking as an issue for Google, as you mentioned in the keynote that that is why you don't like reciprocal licensing agreements?

When you ship a product that has GPL or LGPL software, you need to maintain a mirror on your site somewhere.

We maintain those for the company and we have written all the software for tracking the use of open source software, so it's not that hard for us to do it, but it is time-consuming. That's what's hard about those things.

With commercial software that's true of everything you do [and] it multiplies after a while.

It's not that we don't like reciprocal [open source] licence agreements, we release tons of software under it, it's just that it's easier when we release software to release it under Apache and BSD style licences.

We can say to you: "Take it, please, just take it", it's really very nice.
 

When a piece of Google software reaches the stage of being released as open source, what is the process for that?

So they come to us and they say: "Hey, I want to release this Google software", and depending on where they are on their cycle of development, it's easy or hard.

Sometimes people say "I want to release something" and they have some dependencies that they didn't realise and we say "You can and here's what it'll look like for you".

Most releases, especially the smaller ones, three or four days later they've been given permission from us and we run it through legal and different stuff like that. So it's very, very easy for people to release software.

Patches are even easier, we usually approve those within the hour.

Most of the new projects are approved within two or three days.

For the larger projects like Android and Chrome, they're more complicated, they're bigger and they have a lot of sub-components and that kind of thing. We have to provide a level of infrastructure for them.

For Android we maintain 150 Git repositories for them. We have a lot of software to maintain the repositories and that kind of thing.

They are a bit more work, but that's what we are here for. But it can all be measured in days over the measurable lifetime of the product.

 


Why did Google create Google Code? Why does the world need another SourceForge?

We felt that just one place, with nowhere else for people to go, was a problem.

I think SourceForge is pretty wonderful, and I worked at VA Linux Systems when it was started.

[But] one company having so much of the infrastructure of open source in it, is power.

Which is why I am happy to become a backup, people can keep developing on SourceForge or whatever. I think it is too important to let any one company maintain that much infrastructure for open source.

 

Is Apache the default licence for Google?

Yep.

 

So when something isn't Apache, what is the reason for that?

It's usually dependencies or the projects that we want to have adopt that software are under different licences.

When we released the libjingle project, the projects that wanted to consume it were GPL and BSDs, and so we released under those licences as opposed to the Apache licence. As at the time, the GPL could not consume Apache software.

What we often do in those cases is we will often do a patent clause along with it that says that any Google patents that are in this software, we will give a licence to you and any of your users.

The patent stuff is really important to our group, and we try to bring it to the other licences permissively whenever we can.

Usually when we pick up a licence, we want to be compatible. When we release things for Firefox, releasing under the BSD makes sense -- and so forth.

We release under CPL, EPL, BSD, GPL v2 and GPL v3 and a variety of others.

 


You mentioned in the keynote that Australia has a lot of mentors and not many students in the Google Summer of Code, is this due to Summer of Code being held during the northern hemisphere summer?

This is a problem. The change of seasons is tricky for us, if you look at the number of computer science students in the northern vs. southern hemispheres -- it's hard for us to justify having a southern hemisphere version of it.

For a country of about 20 million people, you have an oversized representation of mentors and about a regular size representation of students per capita. So you're doing OK from a Summer of Code students/per capita point of view, so that would lead me to believe that during a southern hemisphere version of it, it wouldn't make a difference.

That said, the high school orientation version of the Summer of Code that we do is southern hemisphere timed, it's done usually in our winter during December-January. That works out pretty good.

One thing we noticed when we looked at it, was that southern hemisphere universities don't have as long a break as the northern hemisphere universities over summer, on average. It's a little shorter, and you have a longer inter-quarter break.

It's a cunning world.

 

What is your stance on the AGPL after your previous kerfuffle over the licence?

The AGPL as you know is a web clause, so we don't use it inside Google, we don't allow it because it is very hard to track interactions sometimes.

We've had some AGPL projects in the Summer of Code, so it's a fine licence, but it's not for us.

 


You've become a comic book character, is that a tick off the nerd dream list?

You'll laugh, but a lot of people read that comic, man. I never expected that many people to read that comic book, it's telling people we've got a web browser.

Did you see the parodies that people did, like the Godfather parody? They were so funny.

But we love it, and they made me a little thinner.

 
Source:  Written by Chris Duckett of www.builderau.com.au

My Shopping cart

 x 

Cart empty

Contact Us

We try to respond to all enquiries as quickly as we can. Choose a contact channel below and we'll make sure we put you in touch with the right person.
Technical assistance
This email address is being protected from spambots. You need JavaScript enabled to view it.
Web feedback
webmaster@legendarycomputing.com
Sales enquiries
sales@legendarycomputing.com

Who's Online

We have 15 guests and no members online