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)
Ippolita Collective
The Dark Side of Google (continued)
Chapter 3 Google Open Source
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
h4x0r' 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)
--------------------------
Translated by Patrice Riemens
This translation project is supported and facilitated by:
The Center for Internet and Society, Bangalore
(http://cis-india.org)
The Tactical Technology Collective, Bangalore Office
(http://www.tacticaltech.org)
Visthar, Dodda Gubbi post, Kothanyur-Bangalore
(http://www.visthar.org)
# distributed via <nettime>: no commercial use without permission
# <nettime> is a moderated mailing list for net criticism,
# collaborative text filtering and cultural politics of the nets
# more info: http://mail.kein.org/mailman/listinfo/nettime-l
# archive: http://www.nettime.org contact: [email protected]
