Skip to content

You are not logged in. Register orLog In

start:

Native Language Confederation Planet

Bloggings on native language topics by project members - see disclaimer.
Last updated: July 03, 2009 11:00 PM GMT

July 03, 2009

Leif Lodahl :  Norway: ODF is in - OOXML is out

The Norwegian government has made a clear statement in a new catalog covering data standards of various purposes.Public enterprises should not use other file formats than ODF (version 1.1) and PDF as attachment at the exchange of documents by email. This rule will apply from 1. January 2011.The Danish government is still working on a similar decision. A report from the Danish competition

by Leif Lodahl (noreply@blogger.com) at July 03, 2009 11:00 AM GMT



July 01, 2009

Andreas Mantke :  OpenOffice.org at the Linuxtag 2009

Last week I held a presentation about OpenOffice.org Portable at the Linuxtag 2009 in Berlin (see picture below). There was a track about OpenOffice.org at this leading event of openSource software in Europe. As last year I had to open this track with my presentation. So I had to leave the social event "Linuxnacht" on Thursday not too late ;-) We got one of the bigger lecture halls for our OOo-Track and there were many people to follow our presentations. Florian spoke about central configuration...

by andreasma at July 01, 2009 05:28 PM GMT



June 27, 2009

Louis Suarez-Potts :  COPU 2009: Community Matters: Participation, Production, and Sponsorship

The below is the speech I will probably (you never know, and I tend to be parenthetical, digressive, and inordinately fond of extemporaneous speechifying) give at the China OSS Promotion Union’s (Copu) 2009 event to be held early next week in Beijing. Beijing Redflag Chinese 2000 Software Company, a strong supporter of and contributor to OpenOffice.org, has, via Copu, subsidized much of my trip and made possible what I believe will be very productive lectures, meetings, discussions. These include a lecture at Tsinghua University after the Copu speech, and quite probably other presentations and meetings with Chinese officials and groups interested in OpenOffice.org, Foss, and moving ahead fast.

(I always say and also believe that time rushes and that there is always some threat we must apprehend and deal with, be it particularly noxious FUD about the ODF, Foss, OOo, or, sometimes, me. So it shouldn’t come as any surprise that I believe that this year is really quite crucial. Our competitors are not sitting idly by but building blocks of argument to persuade their existing and possibly even new clients of the virtues of their application and its features. Not sure if they talk about their format any longer. And meanwhile, the rampant distribution of “pirated” software continues, eroding not only those with a vested interest in the shrinkwrapped commodities, but also us, the Foss community, for a pirated work is not “free” and does not grant the four freedoms elemental to Foss but is only a bastard version of freeware, only more pernicious, as it comes with the snarky satisfaction for the user that he’s somehow pulled a fast one on the Man. Dream on: In what Illich would have called the Shadow Economy of piracy, the only ones taken for a ride here are those who have priced their freedoms cheap.)




Community Matters: Participation, Production, and Sponsorship
Abstract
I argue 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. 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.
Ask the people involved 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, however conditioned by their work, 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. License enables community but does not determine it; other 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 sam 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 suspect 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.
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, 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 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 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 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 Chinese 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).
It's always a challenge to set up such a 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.

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.
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.


by oulipo (noreply@blogger.com) at June 27, 2009 04:24 AM BST



June 23, 2009

Andreas Mantke :  OOoPortable at the LinuxTag 2009

Tomorrow the LinuxTag 2009 opens his doors. The LinuxTag is a very important place for Linux and open source software in Europe. There are a special day with presentation about and around OpenOffice.org on Friday, 26th of June. I'll give a presentation about OpenOffice.org Portable at 10.00 o'clock on Friday morning. I'm looking forward to meet you in Berlin at the LinuxTag on Friday ;-)

by andreasma at June 23, 2009 03:13 PM GMT



June 17, 2009

Louis Suarez-Potts :  Eccles cake in Shoreditch

Just had an Eccles cake at St. John Bakery and Wine and it was extraordinary. I had never had one before, and that was surely my loss. Actually, the restaurant itself is fairly extraordinary.

by oulipo (noreply@blogger.com) at June 17, 2009 08:11 PM BST



June 07, 2009

Charles Schulz :  It’s official, MS Office looks like The Gimp.

Taken from the GullFOSS blog, Andreas Mertel’s post, this is how MS Office 2008 on Mac OS X may look like, if you don’t pay enough attention:

bild1

Now this is, after 5 minutes of fiddling with pretty much every toolbar possible, how OpenOffice.org 3.01 looks on my Fedora 10:

OOocluttered

To be fair, we should perhaps salute the man/years of development that have been put into both office suites first and then criticize them if we want to. But still, Andreas makes an interesting point: This is how you can render an application unusable when you work along the lines of “more is always better”.

Enjoy your Sunday!

Share This

by Charles at June 07, 2009 03:20 PM GMT



June 05, 2009

Louis Suarez-Potts :  CORRECTION: Trips: China, Japan

A mistaken belief led to this post of mine a short while ago:

“23 June: I fly to Tokyo via Beijing to meet with IPA representatives to discuss contributing to OpenOffice.org. Japan has long been a promise and a problem. Good-Day, Inc., of Osaka has contributed substntially for almost as long as OOo has been around. Indeed, much of the localization effort (to Japanese) is due to their team, and I thank Maeda-san and his company, along with Nakata Maho, for their unstintinting contributions to developing the code into a qualified appication suitable for enterprise use.”

In fact, as was very kindly pointed out to me, this is not the case: Good-Day, though a friend, has not in fact contributed in the way I wrongly described. As was pointed out to me:

“Localization efforts are not due to Good-Day, but tremendous contribution by
ja individuals and SUN K.K., who are not Good-Day's employee. Especially
khirano's coordination has been most noted one. Really surprising, that
such a individuals can do great coordination. Recently, Kubota-san, is taking
over his position, and now he's been doing very well. As far as I know,
no substantial contributions from Good-day, at least of localization.”

My regrets in posting such an error, and my apologies to the all concerned, especially to my friend Kazunari HIrano (Khirano), who has been such a strong contributor to the project and promoter of it. And I welcome Kubota-san!

Alas, errors like the one I made do occur, and I simply ask that when they do that they be pointed out to me. I’ll return the favour :-)

Thanks to those making OOo what it is and even better.

by oulipo (noreply@blogger.com) at June 05, 2009 09:48 PM BST



Disclaimer: all views expressed on this page are those of the individual contributors, and may not reflect the views of the OpenOffice.org Community. If you find any offensive or objectionable material, please notify the Native Language Confederation Leads.

Powered by Planet!