Safe as Milk

Decision making & critical mass

April 1, 2009 gnome 1 Comment

Benjamin Otte’s post today asking how decisions get made (in the context of GNOME) made me think of something I remarked last week.

Last Friday, I attended Critical Mass in San Francisco with Jacob Berkman, and had a blast.

The observation I made was that Critical Mass’s decision making felt a little bit like GNOME’s.

We all met up around 18h on the Embarcadero, all with a common goal – cycle around for a few hours together. Different people had different motivations – for most it was to have fun and meet friends, for some, to raise awareness of cycling as a means to getting around, for others, a more general statement on lifestyle.

After a while standing around, you could feel the crowd getting antsy – people wanted to get underway, and they were just waiting for someone to show the way. For no particular reason, someone who was only a leader insofar as he was the first one to start cycling, we got underway.

After that, thing proceeded more or less smoothly, most of the time. But every now and again, at an intersection, the whole thing would just stop. A group at the front would circle to block the intersection, and those of us behind had no choice but to stop, and wait for someone to get us going again.

Eventually, with Jacob, Heewa and Marie-Anne, we went up to the front to avoid getting blocked up like this, and to set the pace a bit.

When we got to the front, we still stopped every now and again to let people catch up, to keep the group together, and then set off again. Sometimes, we were followed, and sometimes, we’d go 50 yards or so, and for no discernible reason, we were leaders without followers – just two guys out taking a walk. At one intersection, we were stopped for fully 20 minutes. On 3 or 4 different occasions, small groups set off to try to get things underway again, and yet they weren’t followed. Until finally, as if some secret handshake were made, we set off again.

This is the kind of decision making you get when you have a mob with no clearly identified leadership – the direction is set by those who take the lead, and sometimes the ones who take the lead don’t get followed.

It’ll be interesting to see, in the myriad of projects setting direction for the GNOME project at the moment, which group(s) impose their vision and get us cycling on another few blocks, until once again we find ourselves circling an intersection. Will it be Zeitgeist/Mayanna? GNOME Shell? Clutter? Telepathy? GNOME Online Desktop? Or some other small group that captures the imagination of a critical mass of people so that everyone else just follows along?

To be honest, I don’t know – I’m stuck before the intersection, waiting for people to follow somebody, anybody, and let me get moving again.

How do you count your community size?

April 1, 2009 community, gnome, maemo 4 Comments

Way back in the Maemo Summit in September 08, Jay Sullivan put up a slide which talked about spheres of participation in Mozilla.  I threw together a rough approximation of what was in that:

Communities are like onions or planets, with, at their core, the leaders who set the tone and direction for the community. Around this core,many more people contribute to the project with their time and energy, with code, artwork, translations, or with other skills. And beyond, we have forum members, mailing list participants, people on IRC, the people who gravitate to the community because of its vision and tone, and who make the project immeasurably better with their enthusiasm, but who individually don’t commit as much time, or feel as much ownership of the project, as those I mentioned before. Finally, the there is user community, the people who benefit from the work of the community, and which is orders of magnitude bigger.

The boundaries between these levels of involvement are diffuse and ill-defined. People move closer to the center or further away from it as time goes on. A core maintainer gets married, has a child, changes jobs, and suddenly he doesn’t have the time to contribute to the project and influence its direction. A young student discovers the community, and goes from newbie to core committer in a few months.

But the key characteristic to remember is that at the inside we have people who have gained the trust of a large part of the community, and significantly, of the other members of the community at the core. Contribution breeds trust, and trust is the currency upon which communities are built.

Last week as OSBC, I heard different companies claim that they had very large communities of developers, but when I asked about this, they meant people contributing translations, signed up to user forums, downloading SDKs, or developing plug-ins or extensions. When I bore down a little and asked how many were committers to the core product, the impression I got was always the same: very few – because these companies, built up around a niche product, build their business case around being the developer of the product, they require copyright assignment to the core, and becoming a core committer is difficult, if not impossible, if you don’t work for the company behind the project.

So I ask myself, what is the best way to count the size of your developer community? Do you include the orange ring, including translators, documenters, artists, bug triagers and developers who submit patches, but aren’t yet “core” developers? Just the red ring, including maintainers and committers to core modules? Or would you also include all those volunteers who give of their time to answer questions on forums and on mailing lists, who learn about and evangelise your product?

For a project like GNOME, I think of our community in the largest terms possible. I want someone who is a foundation member, who comes along to show off GNOME at a trade show, but has never developed a GNOME application, to feel like part of the GNOME community. I consider translators and sysadmins, board members and event organisers a vital part of the family. But none of these set the direction for the project – for that, we look to project maintainers, the release team, and the long-time leading lights of the project.

I think that you need to separate out the three distinct groups. Your core developers set the direction of the project. Your developer community might include extension developers, documenters, and other people who improve the project, but who do not set the direction for the core (some companies might call this their “ecosystem”). Finally, we have the contributor community, which includes people signed on to mailing lists and forums.

When considering how viable a community project is, calculate the bus factor for the red bit, your core developers. Is there one core maintainer? One company hiring all of the core developers? Then the risk involved in adopting the project goes up correspondingly. The breadth of your contributor community will not immediately fill the gap left if all the core developers disappear.

Gran Canaria: Registration & call for participation open

March 23, 2009 community, freesoftware, General, gimp, gnome, guadec, libre graphics meeting, maemo 2 Comments

For those who missed the next last week, the Gran Canaria Dasktop Summit website got updated last week – and with it, we opened registration for the conference. This is the organiser’s way of knowing who’s coming, and the way for attendees to reserve accommodation and request, if they need it, travel assistance.

We also concurrently opened the call for participation. Since we’re already a little late organising content this year, we’re going to have a pretty short call – please send abstracts for GNOME-related and cross-desktop content to guadec-papers at gnome.org before April 10th (midnight on the date line, I guess).

The procedure is going to be a little unusual this year because of the co-hosting of GUADEC with Akademy – a GNOME papers committee headed up by Behdad will be choosing GNOME-specific content, and a KDE equivalent will be choosing Akademy content, and we are co-ordinating on the invitation of keynote speakers and choice of cross-desktop content.

The thing that got me excited about this conference last yearn and the reason I was so enthusiastic about combining the conferences, is that cross-desktop content. The Gran Canaria Desktop Summit has the potential to be the meeting place for free software desktop application developers and platform developers, as well as embedded and mobile Linux application developers. We will have the people behind the two most popular free software development platforms coming together.

The conference is an opportunity to plan the future together for developers working on the kernel, X.org, alternative desktop environments like XFCE, application platforms like XUL, Eclipse’s SWT, desktop application developers and desktop-oriented distributions. I’m looking forward to seeing proposals for presentations from all over the mobile and desktop Linux (and Solaris) map.

So to your plumes! We’re not expecting abstracts to be works of art, but we are looking for thought to be given to your target audience and what you want them to get from your presentation. Compelling, entertaining and thought-provoking content will be preferred over “state of…” presentations, or other types of presentation better suited to blog posts. Knock yourselves out!

Libre Graphics Meeting fundraiser update

March 18, 2009 community, freesoftware, gimp, gnome, inkscape, libre graphics meeting, maemo, scribus No Comments

With little fanfare, this year’s Libre Graphics Meeting fundraiser has been progressing nicely.

In the three weeks since the announcement of the launch of the campaign, we have raised almost $3,000 in community donation – mostly smaller than $50 – from 71 individual donors. Much of the credit for the campaign this year has to go to Jon Phillips of Creative Commons, Inkscape and OpenClipart fame.

The campaign has started earlier this year than last year, when we were really caught unawares by our difficulties in getting sponsors, and has lacked some of the frenzy of the last campaign, but Jon has been doing stellar work keeping the fire burning, and ensuring a regular stream of donations from supporters of projects related to Libre graphics.

It is hard to overstate the importance this conference has to the communities working on projects like Inkscape, GIMP and Scribus, among others, and to overstate the progress we have made because of these conferences in the past few years in the realm of graphics applications on Linux.

It’s useful to point out that in the Linux Foundation desktop linux surveys, the most popular applications which companies and individuals want for Linux are graphics applications – Adobe Photoshop, Illustrator, Premier, Autodesk AutoCAD, Adobe Dreamweaver and Microsoft Visio are the top 6 applications which people are missing on Linux. This conference is all about encouraging the development of applications destined to fulfil those needs. Also worth noting, when asked whether they wanted the applications above ported to Linux, or they wanted to use equivalent Linux applications where possible, a large majority want to use native equivalents, rather than ported commercial applications.

For any of you looking for a good cause which will go directly to supporting high quality applications that you use, I’d encourage you to contribute to the Libre Graphics Meeting. The conference is only as worthwhile as the people attending it, let’s ensure that we get a critical mass once again and provide energy and momentum to all of the participating projects for the coming year.

Wisconsin Ubuntu fall-out

January 23, 2009 community, freesoftware, gnome, marketing 10 Comments

Bamboozled.

That’s what I am. Bamboozled.

For those who haven’t heard this story over the last week, a young woman in Wisconsin accidentally ordered an Ubuntu laptop from Dell and dropped some college classes because she couldn’t make her internet connection work, because when she put in the CD it didn’t launch, and she didn’t have Microsoft Office, which was a requirement for her online classes.

The story, for me, is the total ignorance that both the university and the ISP have of other operating systems. Instruction manuals have information for Windows, maybe Mac, and outside of that, you’re on your own. A newcomer to Linux can’t get by on their own.

Course requirements list specific commercial programs you need to have. And we have a long hard battle to fight for minds & hearts of the universities, hardware manufacturers, ISPs and everyone else who gives software to users, or who exchange files.

The news station story had a happy ending:

However, we think we’ve helped her get back to school.

Verizon says it will dispatch a technician to try to assist her accessing the internet without using the Windows-only installation disk. Verizon says its high-speed internet does indeed support Ubuntu, but some advanced features and installation disks clearly don’t work with Linux.

MATC also says it promises to accept any of Schubert’s papers or class documents using whatever software she has installed.

Schubert’s computer came with Open Office, a word processing software package that is compatible with Microsoft Word. She says she wasn’t aware it was compatible. MATC promised to show her how to save documents in compatible formats so she could enroll in online courses again.

So – happy ending, right? We’re helping win the hearts and minds, we’ve solved a new user’s problems, and we’ve got some nice press showing how Linux users are neglected by the industry.

Ummm… no. That’s what has me bamboozled.

The story quickly got spun as “news channel said Ubuntu sucks” on tech blogs looking for a big headline. And from there, all of a sudden, the reaction of “Ubuntu fans” becomes the story. The young woman in question got some abuse for not figuring out how to solve her problems – she was “lazy”, “a dumb girl”. The news channel gets lambasted for “unscrupulous reporting”.

We all get lumped in the same bucket. When I go to free software conferences and say I work with GNOME, I hear stories about rude behaviour of others in the GNOME community. Outside the free software world, people don’t make a distinction between the lunatic fringe and people like Mark Shuttleworth or anyone in between.

One of these days that’s going to change. The loony fringe will become the loony fringe, and the mainstream will go mainstream. It’s happened with every “movement” to come from off the radar, and it will happen to us. In the meantime we need to start controlling the story – reminding people what’s important, and generally drowning out the fringe.

Links for getting flights

January 16, 2009 community, gnome, guadec 6 Comments

After my last post, a few really useful links came out in the comments, they’re worthy of getting more attention, on top of sites like expedia.com (where I got my tickets).

Edward Hervey recommended kayak.com – a nice web 2.0 site that aggregates low-cost airlines as well as traditional airlines, shows you prices on or around your flight dates for more options. It didn’t find my train-and-plane combo, while Expedia did, but definitely worth a try.

Nelson pointed to the websites of three airlines that fly to Gran Canaria, for those who want to look to the source: aireuropa.com which I mentioned, vueling.com and spanair.com – as far as I can tell, these are all covered by the above agregator sites.

And sdf (quite possibly a spammer, but maybe not) pointed to tuifly, a German no-frills who flies to Gran Canaria from a wide variety of German sites.

Gran Canaria flights: Now is a good time

January 15, 2009 community, General, gnome, guadec, maemo 4 Comments

I just bought a round trip for the Gran Canaria Desktop Summit, flying out on July 3rd and returning on July 11th, with Europa Air, from Lyon to Las Palmas via Madrid, for €254 including taxes. I found the ticket on Expedia.

This is, quite frankly, very cheap – and I expect that ticket prices will only start going up from here on in.

To all those planning on attending: please buy your tickets now.

If you need some travel assistance, buy the tickets now, and keep a receipt, and ask for assistance afterwards. The longer you wait, the more expensive your ticket will cost, and the less likely it will be that we will be able to partially or fully reimburse you.

It might be worth your while checking ticket prices via a travel agency – since this is a holiday destination, the travel agency may have access to charter flights which aren’t listed on sites like lastminute or expedia. Also, have a look at Easyjet, a budget airline that can give you really cheap flights and isn’t listed in the online reservation sites.

Gran Canaria Desktop Summit site

December 26, 2008 community, gnome, guadec, maemo 2 Comments

Last week, I travelled with vuntz to Gran Canaria, where we met up with Alberto Ruiz, Sebastian Kügler, Will Stephenson and Claudia Rauch,  along with the local organising team Augustín, Miki, Kuka and others to have a series of meetings about the upcoming Gran Canaria Desktop Summit (July 3rd to July 11th 2009).

We had a series of press conferences and interviews interspersed with meetings with the local organising team, among ourselves, with the Cabildo (the local government), and the management of the conference center on a very wide range of topics (and I plan on writing a post or two on some of the interesting issues we’re facing another time).

The conference will be held in the Auditorium, a “palacio de congresos” near the beack in Las Palmas:

This is an amazing theater, and well fit for a symphony orchestra, and on the first day of the conference, the 4th of July, we plan to fill over 1000 seats.

Some of the goals of the conference this year, from the point of view of the Cabildo who are supporting us, are to increase local awareness of free software as a credible alternative, and to grow the local free software industry. As part opf these, we will be working to run some Spanish language tutorials and presentations, and the Cabildo’s press office will be working hard to ensure that the conference opening will get some great media coverage.

With that said, it was reassuring to heard Dr. Roberto Moreno of the Cabildo reinforce his committment to have a conference for the communities, and not let politics and media get in the way of getting together and working. I am hopeful that we can reconcile both, and have some nice local and international coverage of cool stuff coming out of the communities who will be attending.

The conference center is much larger than the symphony hall, and there are some beautiful conference facilities available to us. Space is money, however, so to get the most out of the generous Cabildo support, and to get the most out of the conference, we should limit the space we request (again, no-one wants to see half-empty theaters). We will likely be using the two San Borondón halls plus the Alegranza hall for the major parts of the conference, with a couple of other halls for smaller presentations.

What you don’t see in the pictures is the magnificent panoramic view of the sea which you have in the Alegranza Hall (where we’re thinking of putting sponsors stands and hang-out space) or the similarly-sized but lower-ceilinged room  (San Borondón B) to the left of San Borondón A, which can be split into 5 classroom-sized  halls for small presentations or BOFs.

The visit went great, and reassured me that everyone is more or less on the same wavelength. We’re a little behind on a couple of things, but nothing we can’t catch up with quickly, I hope. The local team are great, and I expect the conference to become *the* place to go for free desktop developers all through the stack (from FreeDesktop.org to application developers) this July.

Increasing Ecosystem Co-operation

December 20, 2008 community, freesoftware, General, gnome, marketing, work 5 Comments

Reposting from Neary Consulting: This is an article accompanying the presentation I gave at MAPOS 08 in London on December 9th 2008.

Moving the Mobile industry from purchasing to co-development in free software communities

Recently, Matt Aslett wrote an article about the way that attitudes to free software evolve over time within a company, using a graphic he got from the Eclipse Foundation, based on some Nortel funded research. Software sneaks in on the ground floor, going from simple use of components to a real understanding of community-driven development, resulting, long-term, in building free software projects and strategies.

Matt sees an evolution in attitudes as the software and its value is discovered at different levels of the organisation, before finally the business development side of the company picks up the ball and drives free software into the heart of the company’s product strategy.

I have also seen this learning process in action, but I would express it differently. People discover the value of the freedoms granted by free software one by one, more or less independently of their level in an organisation – exploring each freedom before discovering its limitations, and thus discovering the value of the next freedom, and qualifying for the next level.

The core freedoms  in the Free Software Definition which are granted to the user of free software are:

1. Freedom to use
2. Freedom to modify
3. Freedom to share, freedom to redistribute
4. Freedom to participate

As companies start to integrate free software components into their products, they discover the value of these freedoms one by one.

Use

The first thing that people see about free software is FREE! As in zero cost. The days when companies reject a product out of hand because they don’t have to pay for it are gone – Linux, OpenOffice.org, Apache, Red Hat and a plethora of other “free” products have proven themselves in the marketplace, and companies are now prepared to allow free software components into their solutions, after appropriate consideration of the licences involved.

To quote one attendee at MAPOS 08, “why would I want to write a compression library, when I can download the best one in the world from zlib.org?” In the area of specialised components for secure communications, compression/decompression, a commodity kernel, and a bunch of other situations, it is appropriate to use free software components off-the-shelf. We expect them to work, and we don’t expect to ever need to talk to the maintainer.

Free software components are in use like this in thousands of systems solutions and commercial products, often without their authors even being aware of it. The main advantage of this for a systems or product company is a saving of time and money, through having a fully functional component without having to go through a purchasing process, and a reduced software bill of materials. An additional advantage is the simplification of your licensing due diligence, thanks to the relatively well-understood consequences of the various popular free software licences.

The difficulty arises when the software doesn’t meet your needs. In many cases, libraries are written by an individual to scratch an itch – it works for him, but is not quite up to your requirements. As one friend of mine put it: “Open Source: 80% as good as the last guy needed it to be”.

Perhaps it’s software that works on 32 bit platforms, but has never been tested for 64 bit. Perhaps it has not been ported to ARM or MIPS. Or perhaps the author simply never imagined that anyone would want the feature which you find indispensable.

In this situation, you can always ask the software author to write the feature or fix the bug for you – but since there is no client/supplier relationship between you, it is entirely reasonable for a volunteer to put your request on the long finger, or reject it outright.

At this point, you realise the value of having the source code – you can modify the software to meet your needs, or pay someone else to do it for you.

Modify

Being able to modify software that doesn’t quite meet your needs is amazing. This is the way things used to work by default, but the shrink-wrapped software revolution of the 1980s got everyone used to the idea that software was a valuable asset to be protected from public view at all costs. When I worked for Informix in the late ’90s, we used to refer to the source code of our leading product as “the crown jewels”.

With the widespread acceptance of free software as an alternative, developers are no longer surprised when they may see how a program works, and change its behaviour. This ability brings two important and immediate benefits – you have control of the behaviour of the software, and you can adapt it to suit exactly your needs. The old choice of build vs buy has become: build vs buy vs extend.

This situation is common in software services companies which provide vertically integrated “solutions” to corporate clients. You take components where you can find them to speed up initial development, stick everything together with duct-tape, hack whatever you need in whatever libraries you’re using to make everything pass the client’s integration tests, and then publish a set of .tar.gz files somewhere on the website of the company to fulfil any licensing requirements.

This control and ability to tailor a solution comes at a price, however. Over and above the cost of making the changes, your team is lumbered with a maintenance problem. Let’s say that implementing the features you need on top of a component the first time round takes a month. Fixing bugs in the features when it has been rolled out can take another few weeks. A few months later, the upstream product you’re based on goes and releases a shiny new version, with lots of compelling new features that you really want.

The cost of integrating your features into the newer version, and doing extensive regression testing before rolling out the new version, might take you another 6 weeks. It is not unusual for time spent integrating your work into later versions to quickly outweigh initial development time and investment. Inconveniently, this is typically effort which is not budgeted for beforehand.

After a company has run into this problem a couple of times, over the course of a year or two, someone will usually suggest that you propose that the features you have developed be sent upstream to the projects you work with – if the feature is accepted, you have solved your maintenance problem, it will be in all future releases of the project, and all of that tricky integration work and regression testing work will get done upstream, as part of normal maintenance.

Redistribute

And so you tell your star hacker Jack that he has two weeks to get your 5,000 line patch down to manageable size by getting your work integrated upstream. (when I said this at MAPOS, no-one laughed – so maybe this does not sound as ridiculous as I thought it did).

He diligently goes to work, cleaning up his code, getting rid of all the warnings, spliting up the big diff into small manageable chunks, creating accounts in 10 different bug trackers, signing up to a dozen mailing lists, creating 47 bugs with terse descriptions, attaching proposed bug fixes, and for major features he sends email telling people that the feature is there and asking for review.

By the end of a frantic month, two weeks more than he was given, he reckons that if everything he’s submitted is accepted, your 5,000 patch will be down to a more manageable 2,000 line patch.

What happens next is… underwhelming.

Major features and bug fixes lie unreviewed for weeks or months. Those that are reviewed need changes which take time and effort. Some patches are rejected outright because they’re too big and the feature is difficult to review.

A post mortem analysis of the project of “giving back to the community” might identify some of the following conclusions:

• Not enough time and resources were devoted to advocating your changes upstream
• Personal relationships between Jack and the project maintainers led to a much higher acceptance rate for patches and feature requests
• The projects were initially evaluated on technical grounds, no thought was given to the developer community underpinning it
• In some cases, maintainers priorities were ill-understood

There are two common conclusions that people make from this kind of analysis;

1. It’s not worth it. They don’t want our work, and the time we’re spending is costing us more than maintaining out-of-tree patches
2. Perhaps if you had engaged with the projects before modifying them heavily, or had been regularly sending contributions, that the maintainers would have been more encouraging, and might have been more prepared to consider your work. If someone from your company was a maintainer or committer already, you would have had a valuable short-cut to getting your agenda implemented in the upstream project.

If you choose door number 1, you will go no further in your quest to really understanding free software processes. This is a reasonable thing to do, but the costs involved are often miscalculated. In addition, the benefits of influencing upstream projects are often vastly underestimated.

If you choose door number 2, you have concluded, in short, that it is madness to include a component in one of your products and exert no influence with upstream projects.

Participate

To have influence, you must understand how the community around a project works. Someone within the team must become an active, trusted member of the community. Once they have gained the trust of the community through their contributions, there may be some procedure to follow for them to become a maintainer of the project, or to gain commit privileges.

These considerations are not technical, for the most part. Friendship and trust are fuzzy human concepts. And this more than anything else brings me to my final point.

Community is hard

For a start, every community is different. They all have different people, different behavioural norms, different dynamics, different forums for communication.

Taking GNOME Mobile as an example, there are 18 projects in the GNOME Mobile platform, with another 10 or so in incubation. Within that, we have a large number of projects housed on gnome.org, and governed by our rules, procedures and conventions. And yet each project has its own set of maintainers – GTK+ is maintained by a committee of around 10 people, EDS is maintained principally by Novell employees, gtkmm has one core maintainer, and so on.

On top of this are a number of freedesktop.org projects, and a couple more which are not under either of these umbrellas. To be an effective influencer of GNOME Mobile, you need to learn the culture of over 20 projects, of wildly varying sizes and baggage.

There are a number of issues to bear in mind when you approach a free software community for the first time. The main one is that while the vast majority of projects think that they are welcoming people with open arms and are very welcoming, if you are a stranger to their land, it is very likely that you will be getting exactly the opposite message.

In some cases, the extent of the welcome is “go and read wiki page telling people how to contribute to the project”. In other cases, no wiki page exists. Occasionally, you will be told that you’re asking your question on the wrong mailing list, or in the wrong way, or that you should read the relevant documentation first. It is not unusual for people to answer questions with a very terse answer – perhaps a link to a mailing list discussion or web-page where the answer can be found.

In general, all of these things are intended to fulfil a simple goal – get you the information you want as quickly as possible, in a way that wastes the time of people already in the project as little as possible. An admirable goal indeed, but as a newcomer, this is not how people are used to being welcomed. Eric Raymond wrote extensively about this in his essay “How to ask questions the smart way”.

Indeed, one of the hardest things to do as an outsider looking in is to evaluate when a community is healthy and viable, and when it has problems which will prevent you from working effectively in partnership. Few resources which talk about healthy free software community projects exist – “Producing Open Source Software”, by Karl Fogel, is something of a bible on the subject, and should be required reading for anyone considering investing in free software. I have also found some presentations, including Simon Phipps’s 2006 OSCon keynote “The Zen of Free” and “How Open Source Projects Survive Poisonous People” by Ben Collins-Sussman and Brian Fitzpatrick, to be excellent resources in helping identify traits of what makes up a healthy community. Two other useful papers which include metrics on measuring the openness of a community, including its governance model, are Pia Waugh’s “The Foundations of Openness” and François Druel’s Ph.D. Thesis (in French) “Évaluation de la valeur à l’ère du Web ” (PDF – rough translation: “Measuring value in the era of the Web”).

Some of the considerations when evaluating a community are whether there is clear leadership, whether that leadership is an individual, a group, or a company, how the leaders are chosen (if they are chosen), what technological and social barriers to participating in the project exist, whether the community processes are documented and transparent, what recourse one has if one feels badly treated, what the behavioural norms of the community are (and whether they are documented) – the list goes on. Pia’s paper in particular gives a great overview in the section “Open Governance”.

Call to arms

And so I close with a call to arms to both free software communities, and companies planning on developing an “open source strategy”.

First, developers, document your communities. Think of yourselves as guides, explaining the cultural quirks of your country to a newly arrived immigrant. Be explicit. In addition to explaining where and how your community works, document how one gains trust and responsibility. Ensure that a newcomer can learn quickly what he needs to do to become a citizen and from there a project maintainer. I am not saying that it should be easy for someone to become a maintainer. What I am suggesting is that it should be easy to see how one becomes a maintainer before doing it

Next, project managers, software developers, company leaders: please, please, please – save yourself time and money and, when you reach the point where you will be building products which depend on good free software components, let the second thing that you do, right after a technical evaluation, be to evaluate the health of the community. A community where you can earn influence and guide the project to better meet your needs is a better long-term investment than betting on a slightly technically superior solution with an unhealthy governance model.

You are building products that you will be selling, supporting, and hopefully profiting from. In this situation, does it really make sense not to have the developer’s ear?

Go in GNOME

December 4, 2008 gnome 5 Comments

Following on from my post earlier today, here’s the program I use to play Go in GNOME, usually: Quarry.

Quarry is a beautiful application which hooks in with a number of different game engines for Reversi/Othello, Go and a game I’ve never heard of called Amazons.

It has some very annoying tics (like asking you for every game you’ve played if you’d like to save it when you quit the application, not being able to undo a move against the computer if, for example, you play a stupid move by accident), it’s missing some pretty important features like integration with IGS or NNGS, and it doesn’t appear to be in active development, but it is the best native GTK+ go game that I’ve seen.

There are also some other Quarry quirks, including an opening window which is quite mystifying. That’s something the program shares with the other Go program I use, CGoban, another discontinued free software Go program (being rewritten in Java, if I’m not mistaken). The CGoban opening screen contains the enlightened button “Go Modem” which is, you might have guessed, the button you must press to start a game against a computer player.

Anyone have a lead on a really nice user-friendly Go game that can play on IGS and against GNU Go? Ideally, one that has been ported to a Nokia N810.