One of the primary functions of a community manager is to put governance in place where it is appropriate to help your community run effectively. Governance is a funny ‘ol word though, and everyone has their interpretation of what exactly it means, to what extent it should be used and how required it is. Like any kind of community work though, there is no hard and fast rulebook about how things work - good judgement is the best method of determining exactly how your community should be governed.

The problem is that that bad governance can really bugger up a community. The concept of governance itself is to put in place processes and rules that are universally understood and accepted by the community in an effort to establish a semblance of control and guidance of the community and its growth. Get it right and your community feels well run, not restricted by bottlenecks and effective to growth. Get it wrong and it feels like a bleedin’ great ship that is impossible to turn around.

The problem is that governance can very quickly turn into bureaucracy if you are not carefull. Bureaucracy is simply governance that refuses to change, despite a better method of governance becoming available. If you put rules in place and refuse to change them because they are the rules, your community gets bound in red tape and will heartily suck for all involved.

Again, it all really comes down to common sense and a measured approach. A few things to bear in mind when considering the formation of constitutions, councils, mandates and other governance hop-scotch:

• Not every community needs a council.
• Setting up a council for the sake of having a council is a bad idea. Having a council does not make your community look any better, more mature or better equipped to do its work.
• Before setting up a council, justify its existence. Justify what problems it will solve and what it seeks to achieve.
• Always regularly re-assess the processes and effectiveness of your governance. Things change, community change, people change…and so will the effectiveness of your governance.

Also, one final note. One of the most wonderful elements of Open Source is the diversity of people it brings along. However, Open Source also has its fair share of Civil Servants who get a kick out of councils, constitutions, boards, elections and what-not. While these people can be useful, and many have the right intentions and balance, beware those who believe that governance is important just for the sake of having governance - invariably this can result in Civil Servant death-matches where there is a fight for power, and the real people who actually care about doing interesting work in the community just get to sit there and watch a pointless power struggle. The best governance is invisible - it just exists and helps cool people to do cool things.

In part 2.4.3 of Ulrich Drepper's excellent How To Write Shared Libraries (which unfortunately is a bit out-of-date these days) Ulrich suggests replacing arrays of constant strings by a single concatenated string plus an index lookup table, to avoid unnecessary relocations during startup of ELF programs. Maintaining this string pool is however troublesome, it is hard to read and difficult to edit. In appendix B Ulrich lists an example C excerpt which contains some code for simplifying the maintaining of such strings pools, after an idea from Bruno Haible. In my opinion however that suggestion is not that much simpler, and requires splitting off the actual strings into a seperate source file. Ugly!

Some Free Software uses string pools to speed up relocation, e.g. GTK+. Some development tools like gperf contain support for string pools.

All solutions for string pool maintaining I could find on the Internet were not exactly beautiful. Either they were completely manual, manual plus a validity checking tool, or very very cumbersome. Googling around I was unable to find a satisfactory tool for this purpose^[1].

After Diego Petteno complained about my heavy use of arrays of constant strings in libatasmart I sat down to change the situation, and wrote strpool.c, a simple parser for a very, very minimal subset of C, written in plain ANSI C. It looks for two special comment markers /* %STRINGPOOLSTART% */ and /* %STRINGPOOLSTOP% */, moves all immediate strings between those markers into a common string pool and rewrites the input with the strings replaced by indexes. Code accessing those strings must use the special _P() macro. With these minimal changes to a source file, passing it through strpool.c will automatically rewrite it to a string-poolized version. The nice thing about this is that the necessary changes in the source are minimal, and the code stays compilable with and without passing it through the strpool.c preprocessor.

Here's an example. First the original non-string-poolized version:

static const char* const table[] = {
	"waldo",
	"uxknurz",
	"foobar",
	"fubar"
};

For later use with strpool.c we change this like this:

#ifndef STRPOOL
#define _P(x) x
#endif

When passed through strpool.c this will be rewritten as:

/* Saved 3 relocations, saved 0 strings (0 b) due to suffix compression. */
static const char _strpool_[] =
	"waldo\0"
	"uxknurz\0"
	"foobar\0"
	"fubar\0";
#ifndef STRPOOL
#define STRPOOL
#endif
#ifndef _P
#define _P(x) (_strpool_ + ((x) - (const char*) 1))
#endif

All three versions can be compiled directly with gcc. However, the version that was passed through strpool.c compresses the number of relocations for the table array from 4 to 1. Which isn't much of a difference, but the larger your tables are the more relevant the difference in the number of necessary relocations gets.

A more realistic example is atasmart.c which after being preprocessed with strpool.c looks like this. In this specific example the number of necessary startup relocations goes down from > 100 to 9.

I am note sure if the parser is 100% correct, but it works fine with all sources I tried. It even does suffix compression like gcc does for normal strings too.

Footnotes

Hi, all! My blog's desktop feed has recently been added to Planet GNOME, and so here is a quick introduction:

My name is Henri Bergius and I am a free software hacker focused on things like the Midgard framework and some location-aware applications for desktop and mobile. I work at Nemein, a small Finnish CMS consultancy building stuff on top of Midgard. I'm quite interested in emerging web standards like microformats, GeoRSS, attention profiling, and in building free maps.

I've been a fan of the GNOME project since the early beta days, and while I currently mostly work on Mac, I still keep following the project actively. I've a speaker in four GUADECs, starting with a presentation about Open Source CMS in Dublin, and followed with geo-focused presentations in Vilanova, Birmingham and Istanbul. As a member of COSS steering group, I was also one of the people behind the (unfortunately unsuccessful) Tampere GUADEC+aKademy bid.

Here is my new hackergotchi:

I recently spent a few days trying to track down a bug in Review Board with our unit tests. Basically, unit tests involving uploading a file to a models.ImageField would fail with a validation error specifying that the file wasn’t an image. This worked fine when actually using the application, just not during unit tests.

The following code would cause this problem. (Note that this isn’t actual code, just a demonstration.)

After a good many hours going through the Django code, expecting there to be a problem with file handles becoming invalidated or the read position not being reset to the beginning of the file, I finally decided to look at PIL, the Python Imaging Library. It turns out that at this point, due to some weirdness with unit tests, PIL hadn’t populated its known list of file formats. All it knew was BMP, and so my perfectly fine PNG file didn’t work.

The solution? Be sure to import PIL and call init() before the unit tests begin. If you have a custom runner (as we do), then putting it in here is appropriate. Just add the following:

Hylke Bons drew a new logo for Banu yesterday. I had requested him for a cuddly brown bear, and adapting Linus's words for Tux, said the bear should look contented and happy, as if it's just had a lot of honey :) Hylke replied within 2 hours with this logo image which is the sweetest bear I've ever seen. It even seems to be hiding a jar of honey behind it :) It's amazing he created it in so little time. Thank you Hylke!