The Dark Side of Google: Chapter 3 Google Open Source

NB this book and translation are published under Creative Commons license 2.0 (Attribution, Non Commercial, Share Alike).
Commercial distribution requires the authorisation of the copyright
holders: Ippolita Collective and Feltrinelli Editore, Milano (.it)

Translation: Patrice Riemens

Theory and Practice: ‘open’ is not ‘free’

‘Free Software’ and ‘Open Source’ are terms, often used as synonyms, referring to code or portions of code. Though both terms often are used to describe the same objects, their perspective is radically different. ‘Free Software’ is a term coined in the beginning of the eighties {of the previous century} by Richard Stallman, and is about the absolute freedom it allows the user to use, modify, and improve the software. This liberty has been precisely set out in the {famous} Four Fundamental Freedoms:

(…)
[Follows here, for a few pages, a general description of Free Software / Open Source and its history, Free Software Foundation, etc. I'll translate it later, it's fairly common knowledge stuff, and I need the original English language texts, not always at hand due to failing connectivity...

I resume where Google comes into play - p84/5] (…)

The interaction between ‘free’ methods of development and the net.economy {at large} would lead, in the years following 2YK to an explosion of the number of ‘Open Source’ products as well as to heated political debates around software patenting, digital property rights and generally about ethically and politically acceptable norms of ‘intellectual property’ management.

Google, despite not being a producer of software as such [? means probably Google doesn't produce software for sale, it develops software for its own products and services], was very much involved in the rocky history of F/OSS, was it only because it adopted, like many other dynamic and innovative firms, the F/OSS methods in order to pursue its ‘mission’. The contiguity between F/OSS and Google is one of place and of time. A number of important free software projects were seeing the light at Stanford University in 1998, just as Brin and Page were putting the last hand on the first version of their search engine. Think for instance of SND and ‘Protege’, which were to be extremely successful in their respective digital domains (audio and semantic web).

The Stanford hacker culture (from which in last analysis F/OSS stems from), lending to all students the feel to belong to the same family, it comes as no surprise that the pair, whose formation straddled those very years, was always to have a preference for the GNU/Linux development platform.

Even though there are non-trivial differences between Free Software and Open Source, there are also {many} common elements and shared viewpoints. For the sake of clarity, we will use here the term /’Open Source’/ {‘F/OSS’, for Free and/or Open Source Software} to design the phenomenon variously embracing Free Software, Open Source software and {its manifestations as competitive element in the IT market} [French text : competition |?|]

The first characteristic of a F/OSS community consist in adopting working methods that are open to the collaboration of all comers, meaning that it will potentially accept spontaneous input and interaction from any party that is involved in the creation of digital artifacts, be it a coder, a programmer, or even an ordinary user. In the hacker jargon, this approach has been described as the ‘bazaar’ model and its widespread acceptance stems from the way the Linux kernel was developed in the beginning of the nineties. This project, initiated by Linus Torvalds forms the basis of all GNU/Linux distros {(distributions: software suites, often a whole operating system (‘OS’))}.

The new co-operation techniques developed by the digital underground dispatched Brook’s infamous law [*N7], which up to now had been the bane of IT projects’ development teams. Following Brook’s law, which predicates that the number of errors grows exponentially as complexity and lines of codes increase, a project in which thousands of developers participate must end up in a chaos of unstable code and innumerable bugs. Quite on the contrary, the publication of the source code, and the free circulation on the Internet of the documentation, together with the co-operation and spontaneous feedback of an ever growing number of participants, have all enabled F/OSS communities to demonstrate that it was possible to considerably improve the development of digital artifacts, both process- and results-wise. Software developed this way is usually shipped under a General Public License (‘GPL’), leading to ‘viral’ distribution of products under copyleft.

Despite the fact that the GPL license does not restrict commercial use, it has been often superseded by ‘diluted’ variants, just as has happened with ‘Free Software’, where emphasis on freedom was perceived as too pronounced. This is the case with the BSD (Berkeley Software Distribution) license, which does not restrict closure of the codes, and hence impairs viral transmission, as the ‘free’ code could be augmented with ‘non free’ portions, resulting in an originally free creation becoming proprietary in the end. Other forms of ‘free’ licenses also exist these days: MPL (Mozilla Public License) for instance.  And more are custom-made for various new F/OSS products as they appear on the market.

This way, the market economy also hosts a sustainable development model, and the developers community is becoming the kernel of a truly ‘Open Society’ [*N8], often thought as a chimerical Shangri-La. This imaginary posture is not only determined by the moral allegiance inspired by the practice of collaborative development, but also, and actually foremost, by the fact that F/OSS applications are usually superior to proprietary ones, despite (or thanks to …) the fact that they are often a labour of love.

The era of the ‘Open Source economy’: be good and compete…

The arrival of ‘Open Source’ on the markets has been, according to some observers, the vindication of ‘technological convergence’, a by now somewhat paradigmatic slogan in IT circles. This convergence means the coming together and synergy build-up between various technologies, which up to now had been separate, and were developed in separate {R&D} environments.

Within these often extremely rapid transformations, the creation of open standards has {merely} marked a new phase in the ‘war of all against all’, also known as ‘free trade’, with “co-operate on the standards, compete on the solutions!” as motto. This is also IBM’s catchword, one of the largest players in this field. When even ‘Big Blue’ is willing to co-operate, then the cake must be worth it…

Indeed, for many firms, F/OSS solutions have become one of the few ways left to compete successfully against monopolies (and consolidated oligopolies), and to escape classic style competition, which due to ever increasing investment costs is no longer a viable proposition {for many smaller companies}. But with F/OSS in hand, firms can lower their development costs, and hence the ‘price’ of their services. Firms have been now familiar for long time with the dynamic advantages of networked development and network partnerships: it is a well-known fact that a network’s worth goes up in the square proportion of its nodes [*N9]. The larger the network, even larger the profits /,exponentially so/.

F/OSS would seem to offer a number of interesting guarantees for the development of high added value networks: on one hand it allows the software to remain, in a certain sense, a ‘public good’ (since it follows an open path of development and benefits from community support); on the other hand it helps reduce the migration, or ’switching’. costs, from one system to the other, especially in the case of switching from proprietary models to ‘free’, but even more so, in the case of ‘legacy’ issues (abandoning obsolete platforms). When adopting new technologies, the major expenses reside in the formation of the users, not so much in the costs of acquiring the technology itself, and certainly not in the case of outstanding software carrying next to no price-tag. But the greatest boon, even though it is difficult to quantify, resides in the /creation of an/ entirely new {, attractive} image for the firm adopting F/OSS and its products.

The performances and success of F/OSS has led to various attempts to put its format in practice in various other sectors. Such attempts inevitably went along with the use of exalted formulas such as “Open Law’, ‘Open Science’, or even ‘Open Society’ {though the term had been coined by Karl Popper much longer ago}. Today, the idea of an ‘Open Source Society’ has almost become the paradigm for a new epoch, dedicated to the {collaborative} search of common means to achieve a ‘politics of what is feasible’. ‘Open Source Society’ indeed is meant to consist in an ‘open code’ dispensation where the possibility to provide input for improvement is freely available to all. When expressed in such terms, one can only agree. Yet one might be surprised by the facility with which such a concept, whose origins are in a very precise, technical, IT context, has been {metaphorically} ‘translated’ to philosophical, economic, and societal domains, without very much thoughts being given to modifying or adapt it to the demands of its new usage.

In the branch of the IT industry were it was born and is put into practice, F/OSS, {and more specifically, “Open Source”} has also meant market competition, battle for the best brains, race for the lowest costs, venture capitalism, and mergers and acquisitions to the tune of billions of US Dollars. We have to do here with large markets where capitalism organises itself in a nimbler, more ‘democratic’ way. A business dynamism that is no longer bent on submitting the labour force, but to intimately associate workers to the ‘mission’ of the enterprise, itself increasingly equated with the realisation of individual desires [*N10].

Amidst ever so many firms surfing this wave in the pursuit of various benefits, Google stands again out as the one which sets the tune: “don’t be evil”, avail yourself of F/OSS, it’s free, it’s better than proprietary software, and its developers are proud to be part of it. A look at the Googleplex has shown how this strategy of deep penetration in people’s everyday life has been refined into a fine art: happy, rewarded, and incentised creative employees, producing far more and much better than oppressed workers.
Seducing the hackers: autonomy, easy money, free tools.

Google’s F/OSS exploitation peaks in 2005, just as the firm’s reputation hits low tide due to its competitors’ moves and a some murky judicial affairs [*N11].

Even though Google’s business model was firmly rooted in IT culture and the practice of scientific excellence, the mere usage of the GNU/Linux operating system to run Google’s humongous data center(s) was not enough: a stronger initiative was needed to strengthen further the faith in F/OSS, and focus the attention again amidst a {by now} disparate mass of free production networks.

Developers could no longer be seduced just by providing a ‘authentic h4×0r’ version of the site – or a Klingon one. And the {intellectually} elitist attitude of the in-house academic brains started to wear thin on investors. They expect substantial returns on their investments and are less interested in the cult of excellence, meritocracy, and the attendant academic arrogance, even though their outcome is an invariably outstanding quality of products. It was therefore unavoidable that the period would come to a close where the two founders friend could jokingly quote shares and do a wager on the stock exchange for US$ 2.718.281.828, being the mathematical constant “e”, or to make completely ‘crazy’ moves, as in August 2005, when declared to have sold 14.159.265 Google shares in order to rake up US$ 4bn in liquidity, without telling the investors nor explaining what they intended to do with that money.

A bold strategic move was called for in order to materialise further Google’s aim to invest in research, and to demonstrate that it is possible with such a strategy, to be not only outstanding quality-wise, but also competitive on the markets. This move was to be targeted not so much at the ‘average user’, but at the ‘young brains’, with the future, and innovation as goals. Operationally speaking, this meant to create and nurture a community, by giving it tools and means, and by signing agreements with other firms in the same sector. The F/OSS world was to be brought under Google’s spell.

Google got seriously into sponsoring new F/OSS communities in October 2005: Oregon State University and Portland State University were [each?] granted US$ 3,5 lakhs (see Chapter 1 to improve the quality of their F/OSS development projects, spawning new software. Shortly afterwards the “Summer of Code” programme was inaugurated with a splash, PR being made directly on Google’s home page (and is still accessible today at http://code.google.com/summerofcode05.html)[<< recommended click! -TR].
The message was loud and clear: the best were to be concretely rewarded.

Every coder coming up with a new F/OSS projects or with substantial improvement of an existing one, was to receive US$ 4500. The whole operation was of course meant to be perceived as one big love bum to F/OSS, stressing the fact that there was the strategic ground where innovation was happening. Also, the sympathy of young developers was to be courted by offering them a cash incentive. And finally, Google was seeking to create a real, ‘open’ style community, which it would sponsor.

More than 400 young developers ended up with a reword. Most were students, and most had made improvements or introduced new features in already existing projects, rather than having developed entirely new software packages. They had added all kinds of features to software suites like Apache, Fedora, Gaim, Inkscape, jabber, KDE, Mozilla, OpenOffice, Python, Samba, Gnome, Mono, Ubuntu – and even Google. Quite some success, especially for the firms that were going to benefit as owners of these
projects: IBM, RedHat, LinSpire, Novell, Mozilla.com, sun Microsystems and Hewlett Packard.

A number of these projects, together with those that were developed within the famous 20% freely disposable time of Google employees, were to contribute towards achieving the second goal of the firm’s plan to pony up with the F/OSS world: to provide for development tools and means. By 2002 Google was already offering freely downloadable tools on its site. Today, the dedicated page hosts proprietary projects developed by Google teams as well as the winning projects of the Summer of Code which are not linked to Google’s own products or services.

The “Code” section of the site presents a number of projects by software developers that are devoted to the most diverse programing languages (Java, C++, Python, etc.). Making development tools available is absolutely essential if you want to foster the creation of software and communities, because the investment is directly linked to the instruments that are necessary for that purpose. Those projects that are developed by Google’s own coders are called Google APIs, and are proprietary libraries to ensure the interface and run Mountain View’s /colossus’/ principal services.

A library is a collection of shared subroutines and compiled portions of code that provide services to other, independent programmes needing simplified functions [?]{see en.Wikipedia: ‘library (computing)’}. An eloquent example are the graphic libraries GTK, QT, and FLTK, which make use of the standard visual applications like buttons, menus, icons, making the work of coders easier. Coders will then go to their favourite libraries and will need to write only those lines that are unique to the programme. The libraries will take care of the buttons, the mouse’s moves, the inking of shadows, in short of everything we, as users, are accustomed to. Given the fact that the average coder will be less than enthusiastic about doing all this dreary work her or himself, graphic libraries are an essential link between various projects. One one hand, they lend a certain graphic homogeneity to the different applications, and on the other hand they enable coders to concentrate on the real work without losing time creating interfaces.

There are development communities which take care of libraries in order to provide for generic and transversal [cross-over?] tools needed for solving complex tasks (network connexions, communication between applications, word processing, image compression, etc.). Just like a software suite is made in order to reach out to as many users as is possible, a library is there to be used by the maximum number of developers.

Libraries hence allow coders to create software starting from an assemblage of shared resources, which function as ‘de facto’ standards.

Making use of existing libraries while programming means to benefit from a basis that is already very large and complex, uses existing code in the most effective way, and allows for a layering of competences. Libraries therefore represent a strategic asset both in the dynamics of spontaneous F/OSS co-operation as in the relational economy oriented world of  ‘Open Source’.

Google libraries, the Google APIs run under a proprietary license, hiding to programmers their actual mode of functioning. But that’s not all: they also include a special control device, as the developer who downloads libraries for free needs to authenticate her/ himself by way of an identifying code. This enables Google to trace in an invasive manner all moves and all changes that are made subsequently to the use of its APIs.

Coders making use of these libraries are allowed to integrate Google search in their site and to know its PageRank[TM] {ranking} in real time. They can also make use of software that manage advertisements through AdWords, generate dynamic maps of their data with the Google Maps interface, or open a VoIP account for online telephony with GTalk. In one word, they can deploy Google services as they like, making use of the programming language of their choice, and all this under the watchful eye of Mountain View.

The vast diffusion of Google services goes together with the possibility to personalise them down to the minutest detail. It is possible, by writing appropriate XML documents [*N13], to establish bridges between the various Google service. For instance, all elements of Google’s home page may be tweaked to one’s own requirements, as if it were an application. Same possibilities exist with Google Earth: one can install 3-dimensional surfing on satellite images, or one can highlight geographical areas, or buildings, or weather data. [?]

All these tools, which are intended for those who know how to write code – at least in one language – are essential to create new combinations of programmes, or simply to use whatever Google makes (at least partially) public in its applications [*N14]. There is even a portal, called googlearthhack.com , where one can find numerous tricks and ‘hacks’, so that one can do the most unexpected things with the site, for instance merging satellite maps with any other database.

All the facilities offered /to us/ by the Google libraries carry with them two strict rules to be respected: registering and licensing. In order to activate the functions of the Google API, one need to request for a key first, that is an access code, and to mention exactly to which purpose one wishes to employ it. Only then are the APIs activated. The second requirement is the license. These APIs are not under copyleft: they can only be used up to a certain extent: it is mandatory for instance, to have a Google account, as the hunger for gathering more information never stops; moreover, the maps are the exclusive property of Google (or of an third party), an may under no circumstances be altered. And of course, in case of commercial use, an agreement must first be entered into.

The activation code enables Google to retain total control on the /new/ programs that come about by making use of the APIs. Google can block these applications without any reason being given, or it can simply control either the way they access its services, or the usage that is being made of them. All this comes about because the source code is not public and not free, making it impossible to understand the internal working of the libraries.

Besides getting development done free of costs while still keeping it under control, Google has another {good} reason to foster the creation of communities along this somewhat bizarre formula, which we may call ‘quasi-open’. It can be also put to use to compile even more data, do research, and sell statistics.

To welcome and host for free individual developers’ projects means also obtaining their trust. Allowing people without restrictions to search the database of ongoing projects amounts to trigger a solid chain of users into existence. Moreover, such a costless incubator of young talent secures the availability of a pool of highly motivated human material whose formation, one of the major cost items in the IT sector, has already been taken of in an autonomous fashion, and in way that is in complete alignment with the style of the firm.

The offer of development tools as a form ‘talent scouting’ mechanism has been known for long time: it is, for instance, the battle horse of a few robust {IT} market players such as the Va Software Corporation, which puts extremely powerful computers at the disposal of the F/OSS community for free, together with unlimited bandwidth, memory space, and {even} technical assistance of a kind that is beyond reach to the most. There are two digital Valhalla’s which may claim world-wide fame a a number of project hosted far above that of any competitor: sourceforge.net and freshmeat.net – and both are property of Va Software. So big is the appeal of such portals that even very small projects appearing on their front pages will attract hundreds of unique views. All projects hosted on code.google.com also have a sister page on freshmeat or sourceforge.

Thus, all the {ensuing} applications will have Google’s visibility together with all the services offered by /the/ Va Software /colossus/: discussion forums, mailing lists, debugging tools and machines, control devices such as CVS (Concurrent Versioning System), controlling the versions, editions and changes {made to} /of/ the code.

It is not difficult to imagine how, with data bases used /for free/ by thousands of coders at its disposal, Va Software can offer an outstanding ‘business to business’ service to companies that are active in the domain of F/OSS – and not only to those. Its data mining represents a virtual heap of gold in the feverish world of billion Dollars deals. RedHat, Microsoft and many other {corporate heavies} are among the advertisers and sponsors of sourceforge and freshmeat.

There are many ways to bring F/OSS developers and firms going for F/OSS together. In Italy {for example}, Sun Microsystem allows you to publish your CV on a Google Map API through its javaopenbusiness.it portal. It is up to the developers to create their own profile, helping thereby Sun Microsystem and Google to sketch a map of Italy’s F/OSS resources with the tools they provide.

And so Google can bank on advancement of its products being done by hundreds of users, and this at next to no costs. To which one can add the organisation of talent competitions such as the ‘Summer of Code’, serving both the development and the advertising of its services. And finally we see extremely dynamic methods of recruitment: Google now even practices video-hiring  at http://video.google.com where enthusiastic employees and Sergey Brin himself will tell you all the benefits of working for Mountain View [*N15]
Hybrid worlds of university and enterprise

With the benefit of hindsight, the coming together of Google and the world of F/OSS would appear to be very much a strategic and calculated move, despite a commonness of origin and purposes regarding the dynamics of collaboration among F/OSS communities which came out of the academic/ scientific scene. The accumulation strategy we discussed earlier is at work even here: Google operates a bit like a black hole, using, even fostering, open codes in order to {subsequently} suck them in and integrate them into its business. A number of changes Google engineers made to open tools have never been made public for instance. This applies to their server ‘GWS (Google Web Server) which is a modified version of Apache, the most widespread F/OSS server of the Web. This amounts purely and simply to availing oneself of the potentials and realisations of the open development formula without sharing developments and improvements afterwards.

An important factor in the relations between Google and the F/OSS world is the fact that it had its origins in Stanford, a university well-known for its capacity to spawn aggressive and competitive, high quality research-backed start-ups. Despite the fact that Stanford did constitute – and still does so – an environment very favourable to F/OSS development projects, the narrow links that exist with venture capitalism make it rather difficult to pursue purely academic excellence once one has left the campus behind.

A small digression on academic research, US style, is needed here to shed light on the intertwined origins of Google, the F/OSS world, and commercial profit-oriented research. On a more general plane, universities in the USA are remarkably intent on capitalising on intellectual creation:
the custom is that a university will retain the copyright on the results of all research projects that were developed within its walls. Universities in the United States are historically connected to business, and are often real businesses themselves. University originating patents on invention made by its researchers bring benefits in all senses of the term, besides enhancing the prestige of research centers, their staff and students.

These universities constitute hybrid environments, public and private at the same time. Up to 2002, public universities were not allowed, in theory at least, to patent their inventions, and the same applied to publicly funded private {research} labs (often at – private – universities). Rights payments impede the free circulation of knowledge in scientific research and makes reproduction, verification and/ or invalidation of experimental results difficult. This was based on the “Experimental Use Defense”, a {legal} principle dating from 1813 that allowed for the free usage of patented technology in {experimental} research. This jurisprudence was quashed in 2002, in Madey vs. Duke University.  John Madey had sued his own university because it made use of a device he had patented to conduct research on free electrons. The {Federal Circuit) Court (of Appeals} ruled that the “Experimental use Defense” was intended to protect a scientist who is engaged in research in a free and {financially} uninterested way, but that within universities such activity was obviously no longer to be considered so innocent, since, even in case there was not a direct commercial connection at stake, it still could be considered akin to a ‘legitimate business’, because it generated funding and benefited the research personnel and the students being educated. And so, any distinction between research for public and research for private goals was made to disappear. [NB interesting article & comments on the case at: http://tinyurl.com/dyd9mc -TR]

Naturally, all projects conducted at Stanford are patented by the university, and this mixture of incentives bestowed on F/OSS projects on one side with a mad run on patents on the other, does not sit well with the ideal, let alone the practice, of ‘research for its own sake’, such is being trumpeted by Google as its strength and its pride.

The issue of patents becomes even more interesting in the light of the fact that Google’s success {primarily} rests on an algorithm invented by Larry Page in collaboration with Sergei Brin, at a time when they both were still researchers at the Computer Sciences Faculty of Stanford. The algorithm that revolutionised the indexing of the Web is hence the property of Stanford, subjected to a regular patent. In the next chapter(s) we will look into how this prodigy functions, how it manages to return results in less time than any competitor, as if it was able to give each and every user “{exactly}what she/he wants”.

(END of Chapter 3)