Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Louis Suarez Potts - Community Matters Copu2009
1. Why Community Matters for Businesses and Governments
The example of OpenOffice.org
GNOME.Asia 2009
Ho Chi Minh City, Vietnam
Louis Suárez-Potts,
Community Development Manager
Sun Microsystems, Inc.
Abstract
I argue here that participatory communities such as those making up successful Free- and Open-Source
communities ultimately depend upon the intangible enthusiasm of its adherents, and that that enthusiasm cannot
be fabricated but only enabled by a supportive environment. I conclude by advocating an on-the-ground
regionalism giving flesh to Web relations in community development, as regionalism quickly brings to local
groups the flexibility that accommodates to social, cultural, political differences around the world.
Basics: What makes a community?
What makes for a free- and open-source software community? I mean a “participatory community,” one more or
less autonomous in operation, and one in which its members crucially are engaged in working together. And
what makes such a participatory community (“community,” for short) is not at all obvious. Assembling a group of
developers and other contributors to work on code licensed under a suitable Foss license, and linking the
contributors using sophisticated tools for communication and production does not automatically produce a
community. Distributed work in fact usually replicates familiar corporate structure. We all know this. The people
may all be working on the same thing, and even be communicating their work amongst themselves, but they do
not necessarily form a Foss community, that is, one in which its agents tend to transcend expectations and
innovate while also performing their regular, expected work.
Ask the people involved in the non-community how they feel about the project they are working on and how they
feel about each other and unless they see themselves as part of a community, as sharing an identity and a
commons that allows them free exchange of the relevant ideas, however conditioned by the work, at hand, they
will likely answer with degrees of indifference. For these, working outside the logic of a community, the work is
nothing more than a job, even though the code that is produced is open. A job is a job: there are always better
ones, and there is no intrinsic loyalty involved. License enables community but does not determine it; nor does
2. the actual technology involved; other intangible factors are required.
Absent the spirit of community, it is difficult to engage the interests of talented developers outside of stakeholder
companies and difficult as well to motivate those in the stakeholders to exceed themselves and do brilliant work.
The result is that for all the investment poured into a project by the stakeholders, the project is always in danger
of dying by attrition and a fatal lack of interest by developers and ultimately users.
One can cite any number of examples of such projects. Indeed, it is the fate of the vast majority of Foss efforts.
Code is put out there—on SourceForge, say, but also on many other equally good sites—and then neglected.
I've read statistics indicating that something in excess of 90 percent of all project code on SourceForge is not
only never downloaded but the project URLs are not even visited. For all practical purposes, there are no
communities associated with these dying projects. (A useful thing to keep in mind is that the vast majority of new
businesses also fail, and if not for exactly the same reasons, at least for similar ones: no market / community to
sustain the endeavor.)
But why even bother to try to form a community? Why not just hire developers or programmers? A Foss
community gives more value than the sum of its parts, or stakeholders' interests. One can certainly work with
free code without a community, but once that investment is withdrawn, there is every reason to suppose that the
code, the project (if there even is one), will simply sink into oblivion. Perhaps that fate is sometimes tolerable and
even desired. But if so, it's not one that most developers, project managers and executives would want. For it
seems like a waste of resources and effort. Loyalty is often priceless but never without value.
Foss “communities” are therefore important in that, at the very least, they limit the risk of wasted resources while
also furthering a culture of development and distribution that exceeds any one stakeholder's expectations. Foss
communities keep projects alive and growing--innovating--and they also do something that is enormously
difficult: they give a project an identity that is far more than the sum of the stakeholder parts and is in fact and
autonomous, in that it is not a predicate of any one stakeholder. To put it in business terms, successful Foss
communities coin a brand identity whose value can be very great indeed.
For many of you this is probably obvious; for others, coming from business or government, Foss communities
persist in being somewhat mysterious. Regardless of your experience, and even if it is obvious to you that Foss
communities matter, the question that I try to answer here may not be: How can one constitute a (sustainable)
community?
Constituting a community
I don't have the foolproof answer to the question I ended with above, How can one constitute a (Foss)
community. A few years ago, at a conference in Brussels, I laid out the governance and some technical
provisions needed to structure a working Foss community. But even if one has the ideal governance model and
code architecture (an extraordinarily important point, is architecture and its impact on governance and
2
3. community—and for all that it's been amazingly neglected), one is still not guaranteed a living, sustainable
community. Laws, as it were, do not make a people; you still need the spirit that binds them into a common
identity. Without that spirit, you have only the letter of the law, not the spirit, and you have very nearly nothing.
But as I stated above, you need more than just spirit.
Political infrastructure is important
Nevertheless, one still needs the political infrastructure in order to constitute a Foss community that has any
chance of sustaining itself. Mere spirit won't do it in the long run. This means that there must be in place the
mechanisms by which any member of the project can communicate to another and freely discuss project matters
with the expectation that discussions have effect and are not just politely ignored. As well, it is generally
important, though I no longer think it requisite, that members have a sense of “ownership” in the community or at
least in what they are doing. It's a feature more important in some areas than others, and as Foss continues to
move away from its origins in the West and find welcome homes in Asia and Africa and India, that model
becomes less essential.
All the same, this is just another way of saying that what global participatory communities need is a structure of
governance that can accommodate difference within the community itself. Governance means here the
guidelines by which authority is coordinated. Given the global nature of, especially, large Foss projects, or even
smaller ones (the Internet knows now boundaries), flexibility is crucial—but so are guidelines that ensure
impartiality and nullify arbitrariness.
The point then is to avoid the tiresome burdens of bureaucracy while exploiting some of its more useful
characteristics, such as the principle that rules are only legitimate when they apply without passion or interest
but with impartial disinterestedness. (I confess: that's not a likely situation, but one can imagine.) A structure as
I've hinted above—minimal and with a focus on communication and implicitly on merit, as demagoguery —
approaches that goal. It allows for a hierarchical flexibility, with some projects being more horizontal than others,
which, for reasons usually having to do with stakeholder preference and code architecture (again, code
architecture determines so much in the political arrangement of Foss communities!), are more vertical. Either
mode can result in a sustainable Foss community, and neither a radically horizontal structure, as can be seen
generally with Linux, or a more vertical one, as in Eclipse, will make or break a Foss community, though I'm sure
adherents of each mode would argue otherwise. (There is no strict methodology for Foss; there are only results,
just as there is no strict, single way in which people body themselves as a nation.)
But what does make the difference is subtler. It can be:
•the personality and charisma of a key member (say, the founder, as in the case of Linux—and of course Apple,
though it is not exactly an open source company)
•the perceived value of the commodity produced, either because of its utility or something else less obvious, and
3
4. the attendant enthusiasm of endusers and non-developer contributors for the product and project, even if they do
not actually code. OpenOffice.org presents itself as an exemplary case. For these, OpenOffice.org speaks to
what they want both as an application and project that they can be part of—and affect.
•extraneous considerations, such as the political and social context of the project, or elements such as the file
format. OpenOffice.org can be used here again; and of course, that's because I'm partial to it.
•An Us vs. Them sense that can attach itself to the project. For many Foss projects, this is actually too easy a
way to form a community. It's easy to attack large, hegemonic companies and to proclaim oneself the freedom-
bearing saviour. It's much harder, however, to actually create something that does what is needed and that
satisfies not just the Geeks among us but also the knowledge workers and others who, well, use the proprietary
software on a daily basis because they must, as part of their job. (Incidentally, these workers don't care about the
drama of freedom playing out on their desktops. They care about doing their work fast and painlessly.) At some
point the rhetoric of defiance must meet the fact of ability, else there is only hot rhetoric or vaporware
•A supportive environment. This can take the shape of government support or cultural or educational or business
support and enthusiasm. It can be subtle: recall that nearly all contemporary successful Foss projects saw their
origins in universities, which gave the talented student the intellectual room and support to develop not only his
ideas but to pass them on to others.
•More broadly, It is vital to have an environment that nurtures young projects and, most importantly, gives
developers the sense that what they and their companies may do with Foss is neither criminal nor foolish but at
the least a sensible strategy. (It should be noted that this provision need not imply a background of wealth. I am
not suggesting that the individual developer be supported by the state or by doing contract work that pays well.
Those scenarios are possible for rather few polities. I am suggesting that Foss be considered as a business and
production strategy on par with others.)
•Finally, and this is a necessity for any participatory community, the community must be able to identify itself.
That is, it must be able to enunciate what it is about: what its goals are or its focus of work or whatever that can
be shared and held as one's own by all who wish to join it.
There are no doubt other anchors to the formation of a Foss participatory community. (Students of political
science can also probably identify elements from Max Weber and Benedict Anderson, to name but two. In many
ways, a community is a community is a community, regardless of the actual nature of its work.)
Authorizing community
Few projects, large or small, have so captivated the political and social imagination of so many in so many
nations as OpenOffice.org. It has done so on the basis of its default file format, which it initiated, the
OpenDocument Format, and because it holds open to every kind of contributor, not just developers, the
4
5. possibility of going beyond the limits on imagination and productive activity imposed by proprietary software.
OpenOffice.org rolls into a single, vast community many of the points sketched above and it is indeed used by
many from South Africa to Venezuela as a vehicle for freedom. (Foss, of course, and by extension,
OpenOffice.org cannot be identified with a single political stance. That doesn't stop others from trying to do just
that.)
But the emergence of OpenOffice.org in the Vietnamese field presents some interesting challenges, not least of
which is the establishment of a participatory community or communities focused on OpenOffice.org (or, for that
matter on other projects). What we see here today is immensely reassuring and exciting, but I'd suggest just the
start.
It's always a challenge to set up such a participatory community—I hope I've made that clear. But the challenge
here lies as much in the coordination with the international groups, as with the identification and articulation of
authority.
The first problem—language--is well known and if not easily resolved, at least it's pretty clear what has to be
done. The second problem is more difficult to resolve. Authority issues have always and will always shadow
Foss projects. Actually, this is a good thing. It is another way of saying that one of the freedoms of Foss lies in
the radical distribution of authority, the effect being that if a developer or group can claim the authority (and
persuade their peers of it) to set up rival projects—forks--then they are free to do so. The distribution of
autonomy is a central characteristic of Foss, regardless of governance structure. That is to say, more or less
autonomous shadow projects—forks—go with the territory. All Foss projects can be forked and most have been;
OpenOffice.org itself has countless small forks, and most are simply non-threatening.
They are non-threatening because they lack the resources of the primary project. The majority of developers
don't want to change without compelling reasons, and stakeholders are not about to change either, without some
compulsion. Each large project has its own momentum.
But that is not so when the project is small or when the social and cultural context do not have a history of
autonomous participatory communities but do have a long history of strong communities enabled and sustained
in part by an outside authority which has spoken them into being and therefore partly constituted them. In this
case, persuading people that they can well, just go ahead and do it, doesn't work and is, as they say, a
nonstarter. Under whose authority, they might ask?
Saying that everyone should be adopt a do-it-yourself approach and use his own authority gets us nowhere, and
as a former scholar of US culture and its international effects, it's hardly a strategy I'd like to endorse. Besides,
there are better solutions: one works within the cultural and social contexts.
I'd like then to propose guidelines for establishing local and regional communities that also communicate with
their international organizations.
5
6. Proposal: Guidelines for establishing Foss communities
Elements:
•Authority comes with what you do. The international organization can testify to your work and identify and
honor what you have done via public documents and statements. But this is only the recognition of work done,
not work that could be done.
•Local communities share the global identity. Their identity is modulated by context but the basic message,
the essential identity of the project is and must be the same. Otherwise, one has effectively fragmented the
project and diluted it.
•Communication with the international organization is essential. Communication can be via wiki, via forums,
mail list, IRC, etc. The important point is to constantly remind others in the world not only of what you are doing
here but of the context of your work. Otherwise, people will forget, as everyone is always more interested in his
own work neighborhood than in some one else's. It is an obligation we all share to represent to others what we
are doing in the larger global community.
•Foss licenses give freedom. But by the same token they complicate the field and introduce the serpent into
the garden, as it were, of competition: for developer attention, if nothing else, but quite often for product market
share. Squelching competing forks does not work, it only causes bad feelings and weakens the primary
community. A sustainable community succeeds, however, not by coercion but by the appeal of its work, identity
and members. Underpinning this appeal is the trust that both local contributors and the international community
put in the legitimacy of the license. It's what enables the project and what I have elsewhere called the
horizonless collaboration of Foss. Anything that challenges that legitimacy challenges the project itself.
These guidelines will not necessarily make for sustainable, living Foss communities. You will still need the other,
more intangible elements, which can be summarized as an enthusiasm for the project and its mission that
transcends any particular commercial claim. Otherwise, it's just a form of marketing, and that does not work to
create a community. Enthusiasm, on the other hand, comes from those within the project and draws others in.
The Importance of Regionalism
I have been advocating that regional and local groups be formed to further the larger goals of the international
project—and vice versa. The advantage of regional groups or organizations—local branches of the international
—is that each local context has its own style of communication and community formation. Not all rely on the
Internet and all use it and the social Web differently. Regional groups accommodate to local differences and
promote the fast creation of networks that bring in new developers, new contributors, new users.
6
7. But no user, no developer will participate in an atmosphere of fear, doubt, uncertainty and in the absence of
strong and usable support. Rhetoric is nice but actions are nicer. It's not about politics; it's about making things.
7