Google: the Godfather of Open Source?
It's well known that Google runs its vast array of servers using a custom version of GNU/Linux. But this is only one aspect of its support for free software. Others include its Summer of Code, now well established as an incubator of both coding talent and projects, and more recently its open source code repository, which offers a useful alternative to Sourceforge.net. Similarly, in porting Picasa to GNU/Linux, Google has made contributions to Wine, while open source projects in Sri Lanka have been the beneficiaries of more direct help, to the tune of $25,000.
But Google is also operating behind the scenes to bolster free software in other ways. For example, it came as a surprise for most of us to learn that the Mozilla Foundation was earning some serious money – figures of $72 million were bandied around - from the use of Google search as the default for Firefox's search engine. This deal alone must effectively pay for a good chunk of the Mozilla project.
In January 2005, Google hired Ben Goodger, the chief engineer for Firefox, in what is proving to be just one of several such moves by key open source coders. At the end of last year, Guido van Rossum, the creator of Python, also joined Google. And most recently, Andrew Morton, the Linux 2.6 kernel maintainer, has announced that he is leaving OSDL to work for the company.
This represents a significant shift in the way the free software community works. Originally, of course, people beavered away on their projects as best they could in their spare time while working or studying. During the first dotcom boom, the early open source companies began hiring the top programmers: kernel coders like Alan Cox, David Miller and Stephen Tweedie went to Red Hat, while many others were snapped up by Linuxcare.
After the dotcom meltdown, key people were forced to find new jobs, with several ending up at the increasingly important OSDL. Against this background, Google's growing collection represents a return to the earlier pattern of concentration of programming talent at one company. But this time, their work is only indirectly related to Google's principal markets.
This is a shrewd move on Google's part. For by employing people like Goodger and now Morton, it is ensuring that the projects they work on – Firefox and Linux – benefit from their full attention, without the need to worry about things like earning a living or keeping management happy. In fact, this is by far the best way for Google to undermine Microsoft's position, with the added bonus that it is not even perceived as taking a hostile stance. Indeed, the company line seems to be that it does not regard Microsoft as a direct competitor, but this is clearly window-dressing.
There is another, less obvious, benefit. Recently, there has been some debate as to whether Google is doing enough to fulfill its moral obligations to the open source world. The argument is over the extent to which Google should be opening up its code, given that much of it is based on free software. As well as legal obstacles, there are also practical ones: the code may be obscure and in reality not much use to "ordinary" users.
In a sense, though, supporting open source hackers is an even better way for Google to give back to the community than simply throwing its own programming "over the wall". The code these people generate is precisely what their respective projects need, rather than what the company produces. Moreover, the more such coveted positions are created, the more working on free software will be seen as a clever career move.
The debate over what responsibilities companies that use free software internally have to open their code was not just about Google. Another major beneficiary of open source software is Yahoo. The latter has been very active in acquiring Web 2.0 companies like Flickr and Del.icio.us, which are certainly aligned with the open source world, but it is a long way behind Google when it comes to supporting open source coders directly. Just as it is in Google's interest to hire free software coders to work on public projects, so Yahoo would do itself a lot of good – in several senses - if it started paying a few alpha geeks to hack for the good of the community, and not just the company.
Glyn Moody writes about open source at opendotdotdot.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide