I was delighted to see that the GNOME Census presentation I gave yesterday at GUADEC has gotten a lot of attention. And I’m pleased to announce a change of plan from what I presented yesterday: The report is now available under a Creative Commons license.

Why the change of heart? My intention was never to make a fortune with the report, my main priority was covering my costs and time spent. And after 24 hours, I’ve achieved that. I have had several press requests for the full report, and requests from clients to be allowed to use the report both with press and with their clients.

This solution is the best for all involved, I think – I have covered my costs, the community (and everyone else) gets their hands on the report with analysis as soon as possible, and my clients are happy to have the report available under a license which allows them to use it freely.

You can download the full report now for free.

(Reposted from Neary Consulting)

Today at GUADEC I presented the results (Slides are now on slideshare) of the GNOME Census, a project we have been working on for a while. For as long as I have been involved in GNOME, press, analysts, potential partners and advisory board members have been asking us: How big is GNOME? How many paid developers are there? Who writes all this software, and why?

By looking at the modules in the GNOME 2.30 release, made last March, we aim to answer many of those questions, and give deeper insight into the motivations of participants in the project.

The GNOME heartbeat - pre-release peaks and GUADEC boosts

Here are our key findings:

• GNOME has a rhythm – there is a measurable increase in activity before release time, and after the annual GNOME conference GUADEC
• While over 70% of GNOME developers identify themselves as volunteers, over 70% of the commits to the GNOME releases are made by paid contributors
• Red Hat are the biggest contributor to the GNOME project and its core dependencies. Red Hat employees have made almost 17% of all commits we measured, and 11 of the top 20 GNOME committers of all time are current or past Red Hat employees. Novell and Collabora are also on the podium.
• A number of top company contributors are consultancy/services companies specialising in the GNOME platform – Collabora, CodeThink, Openismus, Lanedo and Fluendo are in the top 20 companies. As many of these companies grew initially through work on Maemo, this is a sign of the success of Nokia’s strategy around the GNOME stack.

One of the interesting things that we have done for the census is to look at who is maintaining modules by looking at commits over the past two years, and use this data to identify areas of the platform which see lots of collaboration, areas where the maintenance burden is left to volunteers, and areas where individual companies assume most of the maintenance burden.

There are a number of modules in the platform which see a considerable amount of co-opetition, including Evolution, Evolution Data Server, DBus and GStreamer. Most modules in the platform, however, are either maintained to a large extent by volunteer developers, or see the vast majority of their contributions from one company.

I see this information being useful for companies interested in using the GNOME platform for their products, companies seeking custom application development, potential large-scale customers of desktop Linux or customers buying high-level support who want to know who employs more module maintainers or committers to the project.

The GNOME maintenance map, with modules coloured according to the company maintaining them

Update: Two significant omissions in the maintenance map were pointed out to me. After correctly associating a number of commiters to a company, Lanedo is responsible for 16.5% of the commits in GTK+ over the past two years, and volunteers are also responsible for at least 17%. Red Hat are still the largest contributor, with 32% of all commits to the module. libsoup is maintained by Dan Winship, who left Novell to join Red Hat in 2007, where he developed and maintains the module.

Update 2: As I announced in this post, the report is now available as a free download via neary-consulting.com licensed as Creative Commons by-sa 3.0

Open core, Open core,  more Open core… the debate goes on and on, with Monty the latest to weigh in.

When you get down to it this is a fight over branding – which is why the issue is so important to the OSI folks (who are all about the brand). I don’t actually care that much how SugarCRM, Jahia, Alfresco et al make the software they sell to their customers. As a customer I’m asking a whole different set of questions to “is this product open source?” I want to know how good the service and support is, how good the product is, and above all, does it solve the problem I have at a price point I’m comfortable with. The license doesn’t enter into consideration.

So if that’s the case (and I believe it is), why the fighting? Because of the Open Source brand, and all the warm-and-fuzzies that procures. “Open solutions” are the flavour of the decade, and as a small ISV building a global brand, being known as Open Source is a positive marketing attribute. The only problem is that the warm-and-fuzzies implied by Open source – freedom to change supplier or improve the software, freedom to try the software before purchasing, the existence of a diverse community of people with knowledge, skills and willingness to help a user in difficulty – don’s exist in the Open Core world. The problem is that for the most part, the Open Core which you can obtain under the OSI-approved license is not that useful.

Yesterday on Twitter, I said “Open Core is annoying because the “open core” bit is pretty much useless. It doesn’t do exactly what it says on the tin.”

Now, I wasn’t expecting this to be particularly controversial, but I got some push-back on this. Dan Fabulich replied “Ridiculous. Like the free version of MySQL is useless?” Which leads me to think of Inigo Montoya on the top of the Cliffs on MoherInsanity turning to Vizzini and saying “You keep using that word. I do not think it means what you think it means.”

With all this talk of Open Core, clearly some confusion has crept in. Perhaps it’s on my part. So allow me to elaborate what I understand by “Open Core”.

First, companies can’t be Open Core. Products are Open Core. So whereas Monty considers that from 2006 on, MySQL was not an “Open Source company”, I would contend that MySQL Server has always been, and continues to be, Free Software, and an Open Source product. That is, not Open Core.

Open Core for me means you provide a free software product, improve it, and don’t release the improvements under the free software licence. In my mind, Mac OS X is not “Open Core” just because it’s based on the NetBSD kernel, it is proprietary software.

Perhaps it would be useful to give some examples of what is Open Core:

• Jahia is Open Core – significant features and stabilisation work are present in the Enterprise Edition are not available at all in the Community Edition
• SugarCRM is obviously Open Core. Key features related to reporting, workflow, administration and more are only present in the commercial editions
• JasperSoft BI Suite is Open Core. Lots of useful features are only available to people buying the product.

The key here is that support contracts and extra features are only available if you also pay licensing fees. To take the oft-cited example of InnoDB hot back-up tool for MySQL, you can purchase this and use it with the GPL licensed MySQL Server.

This is why I say that Open Core products “don’t do exactly what it says on the tin” – the features you see advertised on the project’s website are not available to you along with software freedom.

I have talked to companies who deliberately avoid adding “spit & polish” to the community edition to encourage people to trade up for things like better documentation, attractive templates and easy installation – and don’t provide an easy way for the community edition users to share their own work. Other products have an open source engine that doesn’t do much except sit there, and all useful functionality is available as paid modules. Yes, a persistent, skilled, patient developer can take the Open Source version of the product and make it do something useful. For the most part, however, if you want to actually use the software without becoming an expert in its internals, you’ll need some of the commercial upgrades.

There is another name for this which is even more pejorative, Crippleware. Deliberately hobbled software. And that’s what I think gets people riled up – if you’re releasing something as free software, then there should at least be the pretence that you are giving the community the opportunity to fend for itself – even if that is by providing an “unofficial” git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves “an Open Source company” when most of the users of their “open source” product do not have software freedom. It’s disingenuous, and it is indeed brand dilution.

That said, let me repeat – I have no problem with companies doing this. I have no problem with them advertising their GPL-licensed stuff as Open Source. I would just like to see more of these companies providing a little bit of independence and autonomy to their user community. But then, that’s potentially not in their long-term interest – even if it is difficult to imagine a situation where the community-maintained version outstrips the “Enterprise” edition in features and stability.

A few days ago, I took the risk of setting off alarm bells on the GNOME developer training sessions planned for GUADEC this year. It was a risk, and comments from the naysayers reminded me that it’s easier to do nothing than it is to take a risk. I’m happy to say that the risk paid off.

Thanks to all who spread the word, a couple of prospects I was aware of confirmed their presence on the course, and I received a new group booking. The training is now feasible, and we are confirming that it will happen. There is still room on the course, and I expect to sell a few more spots in the coming days.

I did get one interesting suggestion in a Twitter reply to the announcement, and I’ve adopted it. If you are interested in attending one or two of the modules (say, community processes and the GNOME platform overview, but not the practical session or Linux developer tools), you can do so for the much lower price of €400 per module and €750 for two modules, not including a GUADEC registration.

Anyone who would like to avail of this offer, please contact me, and we will take care of getting you signed up.

Thank you all for your help and support!

No, not the film.

While I’ve been back in Ireland it’s been impossible to avoid “Discover Ireland” promoting the country as a tourist destination for locals, with ads backed by an infectiously catchy tune.

I’d never heard the group before, so I went hunting and found Heathers, an Irish duet of teenage girls who seem just a little shy, but when they start singing they belt it out. Very simple – guitar + +2 female voices, with an atypical sound and a heavy Irish accent. They’re pretty great. The joys of the interweb and youth who thinks differently about copyright – there is *lots* of live material from these girls on youtube. They’ve already been touring the US and I suspect that they will make a name for themselves. Well worth discovering.

The take-up on the GNOME Developer Training sessions at GUADEC (pdf brochure) has been below expectations. Without going into the details, we’re in a situation where running the training would cost the foundation and the organisers more money than canceling.

If we have not had a number of people sign up for the training by Wednesday evening, we will unfortunately be in the situation where we will have to cancel the session. The GUADEC organisers sign the final contracts with the university for room reservations on July 1st, and that will increase our costs substantially, so that is our deadline for viability.

I hesitated for a long time before writing this blog. It’s never nice to have to admit that something you thought was a good idea, that you put together and made a reality, might not work out.

Many people have, over the years, said that the lack of training options was a major flaw with GNOME. With this training offering, we gave people what they were asking for, with a two day training course plus the flagship GNOME conference for less than you would pay to attend another technical conference. If we cancel this training session, there will likely not be another. The credibility of the foundation (and, I suppose, my credibility) will take a hit.

I decided to let people know in advance that the session is likely to be canceled, to have a chance to stop that from happening. I have confidence that the GNOME community can come to the rescue here, in some sense.

I am sure that there is interest out there. Perhaps people have not yet gotten budget commitments to send developers along, but that they’re still working on it. Perhaps there are people who really should know about the training who don’t yet, because I haven’t managed to get in touch with them. Perhaps a couple of people were planning on signing up, but haven’t gotten around to it yet.

If you are in one of these categories, please get in contact with me soon. If you know someone who would benefit from the training, please let them know, and point them to the brochure and web page. If I have a relatively small number of commitments to attend by Thursday, the training will go ahead.

Thanks everyone for your help and support – I will keep you posted to any new developments.

• Lunchtime run 17/6/10 (tags: running training)

Who knew that educating people in simple sabotage (defined as sabotage not requiring in-depth training or materials) could have so much in common with communicating free software values? I read the OSS Simple Sabotage Field Manual (pdf) which has been doing the rounds of management and security blogs recently, and one article on “motivating saboteurs” caught my eye enough to share:

Personal Motives

• The ordinary citizen very probably has no immediate personal motive for committing simple sabotage. Instead, he must be made to anticipate indirect personal gain, such as might come with enemy evacuation or destruction of the ruling gov­ernment group. Gains should be stated as specifically as possible for the area addressed: simple sabotage will hasten the day when Commissioner X and his deputies Y and Z will be thrown out, when particu­larly obnoxious decrees and restrictions will be abolished, when food will arrive, and so on. Abstract verbalizations about personal liberty, freedom of the press, and so on, will not be convincing in most parts of the world. In many areas they will not even be comprehensible.
• Since the effect of his own acts is limited, the saboteur may become discouraged unless he feels that he is a member of a large, though unseen, group of saboteurs operating against the enemy or the government of his own country and elsewhere. This can be conveyed indirectly: suggestions which he reads and hears can include observations that a particular technique has been successful in this or that district. Even if the technique is not applicable to his surroundings, another’s success will encourage him to attempt similar acts. It also can be conveyed directly: statements praising the effectiveness of simple sabotage can be contrived which will be pub­lished by white radio, freedom stations, and the sub­versive press. Estimates of the proportion of the population engaged in sabotage can be disseminated. Instances of successful sabotage already are being broadcast by white radio and freedom stations, and this should be continued and expanded where com­patible with security.
• More important than (a) or (b) would be to create a situation in which the citizen-saboteur acquires a sense of responsibility and begins to educate others in simple sabotage.

Now doesn’t that sound familiar? Trying to convince people that free software is good for them because of the freedom doesn’t work directly – you need to tie the values of that freedom to something which is useful to them on a personal level.

“You get security fixes better because people can read the code”, “You have a wide range of support options for Linux because it’s free software and anyone can understand it”, “Sun may have been bought by Oracle, but you can continue to use the same products because anyone can modify the code, so others have taken up the maintenance, support and development burden”, and so on.

Providing (custom tailored) concrete benefits, which comes from freedom is the way to motivate people to value that freedom.

In addition, the point on motivation struck a cord – you need to make people feel like they belong, that their work means something, that they’re not alone and their effort counts, or they will become discouraged. A major job in any project is to make everyone feel like they’re driving towards a goal they have personally bought into.

Finally, you will only have succeeded when you have sufficiently empowered a saboteur to the point where they become an advocate themselves, and start training others in the fine arts – and this is a major challenge for free software projects too, where we often see people with willingness to do stuff, and have some difficulty getting them to the point where they have assimilated the project culture and are recruiting and empowering new contributors.

For those who haven’t read it yet, the document is well worth a look, especially the section on “General Interference with Organisations and Production”, which reads like a litany of common anti-patterns present in most large organisations; and if you never knew how to start a fire in a warehouse using a slow fuse made out of rope and grease, here’s your chance to find out.

Registration for the GNOME Developer Training courses at GUADEC is still open on the GUADEC registration site – and the early bird rate of €1200 is available for all orders received until next Tuesday June 15th. So if you’ve been hesitating or delaying signing up, the time is now!

As a reminder of what’s included in the package, you will get lunch and refreshments both days of the training course, a full professional registration to GUADEC worth €250, and printed materials related to the course to take home with you and spread the knowledge, and two full days of intense Lunix development training with a focus on GNOME. There are four half-day modules, covering Linux development, testing and debugging tools, the social side of contributing to free software projects, an overview of the GNOME and freedesktop.org platform and a hands-on workshop where you get to put what you learn into practice.

this will be a great opportunity to give a boost to your entire team by learning developer tips & tricks on being a productive Linux developer, learning tools and tips to improve performance and memory usage of your applications, and how to get your code upstream more efficiently & reduce maintenance costs.

Registration is open, and we still have a few places left!

I’m delighted to announce the availability of GNOME Developer Training at GUADEC this year. It’s been brewing for a while, but you can now register for the training sessions on the GUADEC website.

Fernando Herrera, Claudio Saavedra, Alberto Garcia and myself will be running the two-day course, covering the basics of a Linux development environment and developer tools, the GNOME stack, including freedesktop.org components, and the social aspects of working with a free software project, being a good community citizen, getting your code upstream, and gaining influence in projects you work with.

The developer tools section will go beyond getting you compiling the software to also present mobile development environments, and the tools you can use to profile your apps, or diagnose I/O or memory issues, dealing with the vast majority of performance issues developers encounter.

This is the first time I have seen a training course which treats the soft science of working with free software communities, and given the number of times that people working in companies have told me that they need help in this area, I believe that this is satisfying a real need.

We are keeping the numbers down to ensure that the highest quality training & individual attention is provided – only 20 places are available. The pricing for the training course is very competitive for this type of course – €1500 per person, including training, meals and printed training materials, and a professional registration to GUADEC, worth €250.

If you register before June 15th, you can even get an additional discount – the early bird registration price is only €1200 per person.

I’m really excited about this, and I hope others will be too. This is the first time that we will have done training like this in conjunction with GUADEC, and I really hope that this will bring some new developers to the conference for the week, as well as being a valuable addition to the GUADEC event.

During my recent adventures in San Francisco, I told a number of people about my jet-lag “cure”, and they found it sufficiently interesting I thought I would share.

On trans-Atlantic flights, you typically take off late morning and arrive early afternoon  when traveling East to West, or you take off in the afternoon & land in the early morning when traveling West to East. There are two steps to dealing with major (>= 6 hours time-zone difference) jet-lag: what you do in the plane, and what you do when you arrive.

For me, when I’m traveling East to West, I don’t sleep much on the plane. I watch movies, get up & walk around, chat to the other people hanging around outside the toilets, read – whatever helps pass the time. This means that when I arrive at my destination, I’m tired – my body thinks that it’s late night and I’ve been awake all day. But in reality, it’s 2pm.

By the time you get out of the airport, get to your hotel and check in, it’s probably between 2pm and 4pm. If you go to sleep now, the chances are that you will sleep for several hours, then go out to eat a late dinner, and have difficulty getting to sleep for the night, resulting in tiredness early the following day. This is the vicious circle of jet-lag.

To break the cycle, here’s where my cure kicks in: get out of your hotel. Your body uses sunlight to set its biological clock, so by getting out in the daylight, you are helping your body to adjust to the new day and night pattern. Getting outside during the day suppresses the natural production of melatonin, which helps put you to sleep. It also stimulates the production of vitamin D, helping combat illness (another consequence of jet-lag).

The absolute best way to get out and get over jet-lag is to get some exercise. Go on a cycling tour of the city, or go running. Exercise stimulates the production of endorphines, making you feel good, and more importantly, after exercise you typically do not want to go to sleep. And a few hours later, when you do go to sleep, you sleep more soundly.

If you do an hour or two of outdoor exercise after arriving at your destination, then go back to your hotel and shower/bathe, go out for a bite around 7pm, and then get to bed at an early but reasonable 10pm, you should be able to have a good night’s sleep, and function all day the day after. I typically wake up very early the first couple of mornings when I travel to the States – which gives me an opportunity to (you guessed it) go for an early morning jog before getting ready to go where I have to be.

When traveling from West to East, the problem is similar, but the lag is in the other direction – you may have a hard time waking your brain in the morning when you travel 6 or more hours back in time.

The same trick works. Avoid excessive sleep in the plane – a couple of hours nap is about all I ever manage overnight on these flights. When you arrive, get outside and moving about for the afternoon. I love to go with the kids to the park when I come back from trips and run them (and myself) ragged with a football, or go for a walk with the family – anything to get us out of the house. To help me get to sleep, as well as skipping most of the previous night in the plane, I take a melatonin pill (purchased in Safeways while in the US, not on sale in Europe for some reason) to help me to get to sleep at the right time. And the following morning, when I have the most difficulty waking up my brain, I force myself with difficulty to put on a pair of trainers and go for a 45 minute jog.

And that’s all there is to it! Typically, the day I arrive I suffer, the day after I can function, but am not 100%, and the the day after that, I am fully adjusted to my new time zone.

Does anyone have any other hints & tips to overcome jet-lag? Comments open!

While I’ve occasionally been critical of Ubuntu as a project, it is a distribution with very open processes, for the most part.

I’d like to compare the experience of a casual Ubuntu user, an engaged Ubuntu user, an Ubuntu developer, and an upstream application developer to the equivalent MeeGo or Maemo experiences.

The casual Ubuntu user gets regular stable updates on a predictable schedule, with long-term supported versions less frequently, but still on a predictable schedule. Stability, releases, this user doesn’t want to know what happens behind the scene, he wants to get software when it’s “done”.

The engaged Ubuntu user can activate an unstable development distribution, and see the work going in as it’s being done! He updates daily, gets the latest and greatest, and occasionally stuff doesn’t work, but he doesn’t mind. The information how to do this isn’t on page one of ubuntu.com, but it’s there, and engaged users tell each other about it.

The Ubuntu developer can participate in the creation of the process by packaging his favourite software, pushing it through a public (although occasionally real-time & in-person) process for inclusion in the holy grail – default installation, or presence on the install CD. He can take care of packaging, shepherd the package through QA, ensure that problems get reported upstream and in general ensure that his package is a good Ubuntu citizen. Even if he doesn’t get the package in the default install, which is quite tough, he can follow public community processes to have it available in the Universe, available to every single Ubuntu user through a simple search of available applications.

The upstream developer doesn’t really care that much about Ubuntu. He develops his application, sees bug reports coming in from users & developers & downstream packagers. He adds features, and concentrates on what he loves best – coding the best app he can.

Now, compare that experience to Maemo, to see how we compare:

For the casual user, not much changes. He gets the software on a device, when it’s “done” (and the definition of done is considerably different for a phone than a PC distribution).

For the engaged user, who wants to follow the bleeding edge, the story gets murkier. In the Maemo world, hardware and software releases have been closely related. Without a Beagleboard or a prototype N900, Fremantle wouldn’t have been very useful. But even operating system updates like the upcoming long awaited PR1.2 are not packaged and prepared in public, so even existing N900 owners can’t follow along with the cutting edge.

There is a promise that the first release of MeeGo will work well on the N900, so potentially there is an opportunity for the engaged MeeGo user to follow along with unstable development – on condition that, like the engaged Ubuntu developer, they’re prepared for the occasional bricking & reflash. But the UX software for MeeGo is being prepared for release – we are told that some closed components are being opened, some others are not ready for release yet. So it is not (yet) possible for an engaged MeeGo or Maemo user to follow along & install a base alpha or beta distribution and update or reflash regularly.

For packagers who would like to propose their software for inclusion in the default repository, or even on the default install, of MeeGo or Maemo, there is not (yet) a clear path to get involved in the process. I could start working on a Maemo port of QuteCom, Shotwell or some other software, but if I did, there’s no way for me to get that software included by default. The current Extras/Extras-testing policy of Maemo has been heavily criticised by some developers – so it might not even be easy for me to make my software available to a large number of Maemo issues.

The upstream developer experience doesn’t change that much. Upstream developers still shouldn’t care about what packagers are doing, and should be concentrating on making the best apps possible. But for major parts of the MeeGo platform, namely the UX projects, the upstream and downstream will be hard to separate. As an upstream developer, I care about being able to follow commits, read Changelogs, do code review, develop and propose features, fix bugs and so on, in the open. For unrelated upstream projects, things also change – due to form factor and UX guidelines, the developer really needs to do a tailor-made UI for MeeGo or Maemo, requiring effort not being spent on features. And because you’re doing embedded development, your development environment becomes that much more complicated, with emulators and cross compilers and SDKs.

The embedded world is a special place, a lot of things change from desktop development, and some of those changes come with the territory. You’re going to have to work with a device emulator, and anything that requires a SIM card, the GPS, camera, accelerometer or any other hardware features, well, you’re going to have to wait for a device to make 100% sure those work. But we can certainly bear in mind the Ubuntu user experience(s) when we are designing the MeeGo community, and ensure that their experience is just as open.

That means open code, and more importantly open processes. It means an engaged user being able to use software that isn’t ready, a packager being able to propose software for inclusion in the OS and ensure its availability to all users of the distribution by following a well defined process, and a developer having a great experience helping to develop great applications.

When I first installed a Linux distribution in 1996 or 97, it was a horrible experience. My friend who had started a few months before me thought it was great, though – I remember, it was Red Hat 5, the first version that had an ncurses installer that helped you through the process.

I was confronted with dozens of questions I knew nothing about and wasn’t equipped to answer. Did I want to create a primary or secondary partition? What was its mount point and filesystem type going to be? What was the manufacturer of my video card? What resolution & refresh rate did I need for my monitor (WARNING: the wrong answer can make your monitor explode!)? What was my IP address, netmask, gateway, DNS server? What keymap did I want for my keyboard? Was my NIC using ISA or PCI? Was it 10baseT or 100baseT? Which driver did it need? Was my mouse a PS/2, serial, Microsoft or “Other” (there was always an “Other”)? And on and on it went. How the hell did I know? What did I care?

But it was a learning experience. Installing Linux was the period in my life where I learned the most about how computers worked, hardware and software. Back then, if you wanted to try out an application you heard about, there was only one way to do it – download the source code and compile it. I had a wad of software in /usr/local, including MySQL, the GIMP, Scilab, and a bunch of other stuff I’ve forgotten. There was no online distribution channel. Free software developers didn’t do packaging, there were no PPAs. If it didn’t come on the install CD, it needed compiling.

It wasn’t better. There were fewer of us. Linux had a name as a hobbyist’s toy for a reason. Those of us that there were had a certain minimum knowledge of our systems. You knew shell commands because there was no other way to do anything. Everyone knew about fstab and resolv.conf and ld.so.conf and compiling kernel modules, because you had to. And every time you installed software, you had the source code – right there on your computer. And you knew how to compile it.

I don’t know if I would ever made a patch for the GIMP if I didn’t have the source code and had already gone through the pain of compiling & installing all its dependencies. I doubt it very much. And yet that’s the situation that the vast majority of Linux users are in today – they have never compiled any software, or learned about the nuts & bolts of their OS, because they don’t have to.

I remember Nat Friedman talking about this in a presentation he made a few years ago about how to become a free software developer. Step 1 was “download some source code”, step 2 was “compile and install it”, step 3 was “Find something you want to change, and change it”. And I recall that Nat identified step 2 as the major stumbling block.

We have bred a generation of free software users who have never compiled software, and don’t particularly care to. Is it any wonder that recruitment of developers appears to be slowing, that prominent older projects are suffering something of a demographic crisis, with hoary old 30 year olds holding down the fort, with no young fiery whippersnappers coming up to relieve them?

Is this a problem? It seems like it to me – so I ask the question to a wider audience. With a second question: how can we get the hobbyist back into using free software, at least for some part of our community?

We’ve been running into some interesting issues with the GNOME census, which are causing us to twist our tiny brains to get useful results. I thought it might be interesting to share some of them.

1. gnome.org – a large number of people commit with their gnome.org address (or src.gnome.org), but have also committed with a different address in the past. So many of you received our survey request twice or more (oops). gnome.org addresses pose another problem too – when attempting to identify a developer’s employer, gitdm uses domain name matching, and some many gainfully employed GNOME hackers use their gnome.org addresses to commit, that doesn’t work very well (oops). Finally, we have observed so far that the response rate among unpaid GNOME developers is much higher than the response rate among professional GNOME developers, which has made identifying employers for specific addresses even more difficult.
2. ubuntu.com – Some Canonical developers commit with their gnome.org address, some with their canonical.com address, and others apparently use their ubuntu.com address. Some unpaid Ubuntu hackers & packagers also commit with ubuntu.com email addresses. So identifying the exact number of Canonical developers & Canonical upstream commits has proven very difficult.
3. Time – many GNOME developers have changed employers at some point, or gone from being unpaid GNOME developers to paid GNOME developers, or changed companies through acquisition or merger. Old email addresses bounce. And yet, it’s the same person. Dealing with time has been one of our toughest challenges, and one where we still don’t have satisfactory answers.
4. Self-identity – One of the issues we’ve had running the survey is that simple domain name pattern matching doesn’t tell the whole story. Does someone who works for Red Hat on packaging and then spends his evenings hacking his pet project count as a volunteer or a professional? We have noticed a significant number of people who commit with their professional email addresses and consider themselves volunteers on the GNOME project. For a problem which is already complicated enough, this adds further nuance to any quantitative statistics which result.

Thank you all to everyone who has taken the time to answer the 3 to 7 questions (depending on how you self-identify) in the survey – the data has been interesting, and has led us to question some of our preconceptions. To those of you who have not answered yet, let me assure you that the email we sent was not a spam, and Vanessa is doing a great job collating your answers and (in some cases) preparing follow-up questions.

Any insights which people might be able to give in elucidating the issues we’ve noticed are welcome! Please do leave comments.

The voting tokens have just been sent out for the Q1 2010 Maemo Community Council elections.

I already have over 100 bounced emails, so if you think that you should have a vote and you have not received an email with a voting token yet, please send me an email or leave a comment, I will look up your Maemo username and send you on the voting token/email combo we have on record so that you can vote.

Voting runs until March 30th – you can find more information about the election and the council in the Maemo wiki.

I’ve been working on a project for the past few weeks, and it’s time to take the wraps off.

For as long as I’ve been involved in GNOME, we have been asked the same questions over and over again: How many GNOME developers are there? Which companies invest in GNOME, and how much? Where can I go for professional GNOME development services? And for as long as I’ve been involved in GNOME, the best answer that we can give is pretty hand-wavey – we talk about hundreds of developers, thousands of contributors, the advisory board, an ecosystem of expert independent companies, but we never do get around to putting meat on the bones.

I decided that we should do something about that, and so for the past few weeks, an intern called Vanessa has been working to help me dissect the underbelly of the GNOME project.

What is the GNOME Census?

We’re aiming to answer three questions as completely as we can:

• Who develops GNOME, and what do they work on? What does the GNOME developer community look like? How many GNOME developers are there?And how many contributors doing things other than development?
• What companies are investing in GNOME, and how? Are there modules where companies are co-operating, or have contributing companies been concentrating on disjoint parts of the project?
• Finally, if you’re a company looking for expert developers for custom GNOME development, where should you go? What does the commercial ecosystem around the GNOME project look like?

We’ve been using tools like gitdm, cvsanaly and artichow to get some nice quantitative data on modules in GNOME git and freedesktop.org repositories. We will be running a survey of GNOME developers, and doing one-on-one interviews with key people in the GNOME commercial ecosystem to go beyond the figures and get some qualitative information about future plans and priorities as well.

So why take on the project?

Well, it seemed like fun. Answering interesting questions is always challenging and interesting. And it also seemed useful – if people are always asking for this information, there must be a reason they want to know, right?

Financially, this is an investment. I am paying Vanessa to help with the study, and it is taking a lot of my time. I initially looked for a sponsor for the project, but reaction was tepid, no-one wanted to bear the full cost of the report, but everyone I spoke to agreed that it would be useful and they would definitely like to have a copy when it got done. So I hit on the following idea for funding the project:

When the report is eventually available, I will be selling some copies to recoup costs. When I have sold a sufficient number to cover the cost of the project, I plan to release the report under a Creative Commons license. Those who are eager to get the results and information sooner rather than later will subsidise the availability of the report for everyone. I have submitted a proposal for GUADEC to present the conclusions of the report, and I anticipate that it will be available under a free licence by then.

Who’s the target audience?

ISVs are interested in knowing how active projects are before committing resources. The GNOME Census will help reduce the uncertainty when choosing GNOME as a platform. GNOME distributors will be able to leverage this report to show the vibrancy, size, activity and commercial ecosystem around the GNOME platform. For companies who have been long-time investors in GNOME’s success, the census will give them well-deserved recognition, especially in areas where that investment has not been very end-user visible, but has had a huge effect on the quality of the user experience. Finally, for companies building software platforms on top of GNOME, and for companies in the GNOME commercial ecosystem, this report will allow swift identification of service providers with a high credibility level through their involvement in GNOME and the core developers who are working for them.

So what now?

We will be launching a survey this week asking GNOME developers who they work for, and whether they have worked for other companies previously – because of the widespread use of gnome.org email addresses in GNOME, unfortunately it has not always been easy to identify companies behind the people. We also want qualitative information on projects you work on, whether you work on GNOME in your free time, and more. We are be breaking down GNOME development by core platform, external dependencies, GNOME desktop, GNOME hosted applications and other GNOME applications. Vanessa will be sending out a very short survey to everyone who has committed to GNOME, and we need your help to make the census as useful as possible to the GNOME project.

Thanks for your help!

I just realised this morning that after a very long call for participation period, we’re now in the last week before the call for participation deadline for GUADEC – you should have proposals in by 23:59 UTC on March 20th to be eligible for selection (although a little birdie tells me that might get extended to the end of the weekend). Of course, I knew that the deadline was sometime in the end of March, but I didn’t realise that we’d gotten so far through the calendar!

So get your proposals in about all things GNOME, GNOME 3, GNOME Mobile, usability, accessibility, webability, open data, free services, scaling the community, developer tools, whatever – but get them in quick. It’s better to get a poor proposal in now & improve it next week than wait until next week to polish what you have now.

For guidelines on a good talk proposal, I really like the OSCON guidelines as a list of good dos & don’ts for conference proposals – in general, make the proposal (and your presentation, if accepted) not about you or your project, but about your audience and what they can do with your project – so clearly identify the target audience & why they would attend, and make the title short & action-based, rather than vague, weird or overly clever.

Good luck to teuf and his merry band evaluating all the proposals!

In honour of the recent discussions on foundation-list, I would like to resend everyone to this piece by Dan Spalding, which I’ve mentioned previously. It had a huge influence on me, and hopefully will on others too.

As a teaser, here’s an extract of the target audience:

Consensus decision making is a model of the society we want to live in, and a tool we use to get there. Men often dominate consensus at the expense of everyone else. Think about the man who…

• Speaks for a long, loud, first and often
• Offers his opinion immediately whenever someone makes a proposal, asks a question, or if there’s a lull in discussion
• Speaks with too much authority: “Actually, it’s like this…”
• Can’t amend a proposal or idea he disagrees with, but trashes it instead
• Makes faces every time someone says something he disagrees with
• Rephrases everything a woman says, as in, “I think what Mary was trying to say is…”
• Makes a proposal, then responds to each and every question and criticism of it – thus speaking as often as everyone else put together (Note: This man often ends up being the facilitator)

It’s rarely just one man who exhibits every problem trait. Instead it’s two or three competing to do all the above. But the result is the same: everyone who can’t (or won’t) compete on these terms – talking long, loud, first and often – gets drowned out.

This is a result of society’s programming. Almost no men can actually live up to our culture’s fucked up standards of masculinity. And our society has standards for women that are equally ridiculous. In one way, we both suffer equally. That’s why we all yearn and strive for a world where these standards – which serve to divide us and reduce us and prop up those in control – are destroyed.

In another way these standards serve those who come closest to living up to them. Sure, we all lose when a few men dominate a meeting. But it’s those men who get to make decisions, take credit for the work everyone does, and come out feeling more inspired and confident.

Like I said, Dan’s piece opened my eyes to my own bad behaviour, and also enabled me to improve as a meeting/round-table/discussion facilitator. Hopefully a reasoned reflective analysis of their behaviour by the most disruptive elements of foundation-list will also have a similar effect on them. I certainly hope so.

Je viens de finaliser aujourd’hui les présentateurs pour l’inauguration de Ignite Lyon. Les sujets sont assez diverses, du vache à lait à l’informatique bio en passant par la course à pied et l’art libre. Pour ceux qui sont plus du tendance entrepreneur, nous avons également des présentations sur la démarche commerciale ou créer sa première boîte jeune.

Voici la liste des présentateurs pour ce premier Ignite Lyon en order alphabétique, sauf modifications de dernier minute:

• Emmanuel Aldeguer: La vache à lait est morte vive la vache à lait
• Laurent Alliod: L’informatique Bio
• Francois Aubriot: The Day after (your PC & iChose)
• Encolpe Degoute: Connectivité, neutralité, universalité
• Gabriel Foin: Démarche commerciale! Pourquoi développer l’esprit positif pour gagner!
• Alain Giscloux: The Digital Washboard: not a musical instrument, not a video game, Only a digital art installation
• Alain Imbaud: Culture Libre ? … !
• Vincent Mabillot: OS-delà (la trancendance divine ou matérialiste des environnements informatiques)
• Dave Neary: Hackez votre corps
• Nathael Pajani: initrd VS initramfs
• Ludovic Rerolle: Comment planter sa première boîte le plus vite possible
• Guillaume Smet: Et si un wombat gérait vos projets informatiques ?
• Florent Souliere: La paresse met la vie (privée) en danger

Avec une salle qui prendrai autour de 100 personnes, les places risquent d’être chères, même si l’entrée est libre!

Je vous suggére vivement d’être à votre place dans la salle D101 de l’Université Lyon 2, Quai Claude Bernard, à l’ouverture des portes à 18h30 jeudi prochain le 4. Les festivités commenceront vers 19h, jusqu’à 20h30 à peu près, avec une pause pipi au millieu.

Vous pouvez également vous inscrire pour manger un bout après l’événement au Chevreuil, ou nous allons nous retrouver quor quelques boissons raffraichissantes à partir de 20h30.

Vous pouvez trouver plus d’informations sur le site Ignite Lyon. A la semaine prochaine!

Oracle laying off GNOME contributors is certainly bad news for the project. It’s particularly bad news because Willie Walker, one of my favourite GNOME contributors, is now out of a job.

I just want to put this in perspective, though. In 2007, IBM made deep cuts in its support of GNOME accessibility, affecting contributors such as Peter Parente, Eitan Isaacson and Aaron Leventhal, who are no longer paid to work on GNOME accessibility work. The IBM cuts were perhaps deeper than those that Oracle are announcing right now (but I suspect that we’re not finished hearing bad news from Oracle). So we’ve been through this (and worse) before.

Next, it’s not all bad news on the accessibility front: other distributions are carrying a small amount of the accessibility mantle (Ubuntu, OpenSuse), with projects like MouseTweaks being funded by Canonical, the Inference lab in Cambridge has been funded for some projects (Dasher, OpenGazer (the newer development of OpenGazer is not yet available for download)) through the AEGIS project, and of course as others have noticed, the Mozilla Foundation has repeated its accessibility grant of the last two years to the GNOME Foundation, and supporting Orca is part of its accessibility roadmap. Mozilla has also funded work to port AT-SPI from Orbit to DBus, and other work on Orca and Accerciser.

So there are people who care about accessibility in GNOME, and there appears to be a potential for funding for accessibility work, for the right people with the right contacts and the right projects.

Perhaps it’s time for the GNOME Foundation to start seeking funds from government bodies, other public institutions and private funding to fund accessibility work for the greater good? I know that we’re currently raising funds for a sysadmin, and have not yet reached the level of support where we can make that position a regular fixture, but accessibility is different.

No one player is willing to put enough funding into accessibility to properly support Orca, gok, Dasher, AT-SPI, Accerciser, MouseTweaks, keyboard accessibility tools like SlowKeys and StickyKeys, and so on – but perhaps there are lots of people who are willing to support a project for a specific feature, or general stability & bug fixing work for a11y on the desktop?

If there is no commercial justification for a company like Oracle to pay two people to work full time on free software accessibility, then it’ll be a hard sell to any other company. But perhaps the GNOME Foundation could bear two full time accessibility employees with targeted grants working on a public roadmap? Raising $250,000 – $300,000 a year for accessibility from grants doesn’t sound that hard.

But then, maybe I’m nuts…