Marketing GNOME, Part 4: Hobbyists

gnome, guadec, marketing 2 Comments

Unfortunately, I won’t be doing the subject justice – by rights, this deserves two or three entries of its own – but I’d like to give an overview of things we can do easily to better market GNOME to hobbyists.

Remember, inform, listen, react is the order of the day.

When I’m talking about hobbyists, what I’m talking about are people just off GNOME’s radar.

  • People who regularly buy computer magazines, and are interested in technology, but who have perhaps never tried free software
  • Students, particularly in science and computing courses
  • Momentum users – the type of person who has been using free software for donkey’s years, and who has perhaps not appreciated some of the recent noises coming out of the GNOME project
  • Developers looking for a project to sink their teeth into
  • Existing GNOME users looking for a way to help out

There are a massive amount of easy targets here, and typically what we’re missing is people to take care of them. What we need to do is start organising, both top-down and bottom-up, to improve our presence on the ground. What we need is information centralisation and organisational decentralisation – you are responsible for what you do in your area, but when you do stuff, you should make sure that everyone knows what you do, and how it works out. Here are just a few things we could be doing:

  1. Contacting journalists in magazines to introduce yourself as a GNOME contact, and perhaps suggest including a LiveCD, or a copy of WinLibre or the OpenCD on the cover – we must centralise journalist contacts
  2. Contact the local university computer club or LUG, and help organise some free software presentations. Invite a well known GNOME developer from the region to come and do a presentation
  3. Use the database of presentation material that we have built up, and give some presentations yourself
  4. Help improve the database of presentation materials that we have 😉
  5. Write articles for the GNOME Journal, or a monthly GNOME corner column for local language magazines
  6. Contact your local magazines offering to translate existing GNOME Journal articles
  7. Start a Spread GNOME effort
  8. Summarise negative and positive reviews of GNOME, and push your conclusions with the relevant developers
  9. Work the forums! Get feedback from our existing users, and make sure that they’re heard
  10. Offer to organise Friends of GNOME not just as a financial ressource, but also as a source of advocates for GNOME

So you live in the middle of nowhere, and you don’t know how to help. Contact your local LUG, contact the local university computer club, propose your services as a member of the GNOME community. Contact the marketing list, contact me, blog about your region, the LUG, the events you’re helping organise. Try to get a small microcosm of GNOME advocacy around your area. If you succeed, and we get lots of those microcosms, all of a sudden they start interconnecting. If there’s a GNOME user group in your region or country, sign up, join in. If there isn’t consider starting one. If you want a well known speaker for a presentation, contact the marketing list, or contact the board.

Everyone add yourselves to the GNOME map! This is our best view of the distribution of GNOME advocates, developers and users worldwide. I recently used the map to find someone in San Diego to man a stand. He couldn’t do it, but the map made asking him possible. I don’t see anyone on the map in Bhutan! Or Mongolia for that matter, Sukhbaatar.

As a summary for this series, the main points to take away are:

  • Most people we deal with prefer a human and personal touch to a mailing list
  • There are lots of things to do – far too many for one person, or even a small group of people. We need to build up a distributed marketing structure
  • Luckily, 95% of what there is to do is easy stuff. One motivated person can change the image of GNOME in their area by getting to know their local press, geeks and politicians
  • Marketing GNOME is about informing people who should know that GNOME exists, listening to the feedback of people using GNOME, and reacting to that feedback in a positive way

Looking forward to seeing you all at GUADEC for the marketing BOF. We’ll be holding it from 10 to 12 on Wednesday morning (although it might be Tuesday) – I’ll be posting the time & place on the wiki.

If you can do what Bhutan do…

gnome, marketing 6 Comments

After mentioning the interest of government in free software yesterday, it gave me great pleasure to see Bhutan adopting a Debian and GNOME distribution today.

Way to go Bhutan! Anyone here speak Bhutanese?

Marketing GNOME, part 3: Public administrations

gnome, guadec, marketing Comments Off on Marketing GNOME, part 3: Public administrations

A fairly obvious principle when talking about target markets is to look at your existing user base, and try to categories and generalise from that. If 80% of your users are 18-25 year old college girls, then if you are targetting 50-65 year old businessmen, you’re probably on a loser.

In GNOME, we have a luxury – lots of people have already installed our software without us having to ask them to do so. So we have a decent sample of the kind of people who are interested by what GNOME has to offer. And a big identifiable group in the free desktop user base (and GNOME in particular) is public administrations – national or local governments (Largo, Birmingham libraries, the UK’s NHS, Itaipu in Brazil), school districts (Extremadura and Andalucia, Tyrol, Macedonia, China), city and state funded social projects (Sao Paolo, Bahia, Linz).

Many of these installations have happened with no help from us – either distributors who base their product on GNOME sold their product and we came along for the ride, or the local governments made their own decisions, usually without managing to contact the GNOME community at all.

Governments are clearly interested in free software, and we should make sure they know about GNOME, and have a place to go to ask questions. That place should be a personal email address, and not a mailing list, because governments can be quite edgy about going public with things like this. And also because, in the words of Tristan Nitot from Mozilla, “Guys are really shy – it’s the Munich Linux thing… They start talking about it and suddenly Ballmer comes in and twists your arm until you cry”.

To get the message out to governments, here’s what we need to do:

  • Get information from existing projects to find out why we were chosen, and model our message based on the feedback.
  • Follow the news. Whenever there is a project in the news about a pilot or a minister talking about a strategic decision to use open formats or free software, follow it up.
  • Co-ordinate. If the contact is in South America, a Spanish speaker should make the first contact (preferably a South American). If in France or North Africa, a French speaker. If in China, a Chinese speaker. When you mail a deployment, mail marketing-list automatically to let people know. This gets the email address and the contact into mail archives. We should probably move to a relationship management module in Drupal sooner rather than later.
  • Keep contact with your local politicians. Send an email to your mayor, or phone the local city’s IT department to invite them to your local user group conference. Send a letter to your minister for technology (or equivalent) proposing a phone call to explain the benefits of free software in government.
  • Keep Dr; Edgar Villanueva’s letter to Microsoft pinned to your wall!
  • Don’t forget the feedback loop! If you get information back from a local government (good or bad), send it back to the marketing mailing list so that we can react to it – either explaining why impressions are incorrect, or working to figure out how to address the shortcomings.

The GNOME Journal articles written by Murray Cumming and Arangel Angov are excellent examples of the kind of feedback which works well – human, and presented to a wider audience than the marketing team.

But we shouldn’t focus too much on creating the message – we have a decent idea already why governments are interested in free software, and if we find that other points are interesting, or points we thought interesting are not that relevant, we can modify our message from that.

The marketing theme can be nicely summarised by a tripleverb.

  • Inform: Make sure people likely to be interested in GNOME know about it
  • Listen: Get their reactions fed back into the system
  • React: Consider modifying our software (or our message) based on that feedback

Marketing GNOME, part 2: Certification

gnome, guadec, marketing 3 Comments

This is another third party developers thing to follow on from my last entry on the subject – but it’s sufficiently important to be treated separately.

If we want GTK+ as a toolkit, and GNOME as a platform, to be adopted in public administrations, and embraced by third party developers, then we need to make sure that it’s easy to write vertical applications for the platform. A vertical application is an application written for a specific use, such as an accounting package, or a programme that surveys air quality, or the application which takes care of all the traffic signals in a motorway tunnel. We also need to make it easy to write mass market software such as VMWare, The GIMP or Abiword.

This means having good developer tools, in particular a good IDE, but it means a lot more than that. Most developers in the commercial software world get by with little more than a C compiler and a debugger. Good profiling (including memory profiling) tools are useful, and they already exist for the most part.

More than tools, what a third party developer needs is a roadmap and a checklist. A list of best practices that he can follow like a “For Dummies” book, and get to where he wants to go learning the minimum amount possible about what’s happening underneath the hood, and a list of things against which he can verify that his application is a good citizen on the desktop.

Here’s what you do to make your app accessible, here’s the right way to interact with GConf, D-Bus, GNOME-VFS, GStreamer and so on.

Update: library.gnome.org, when ready, will be a huge step in the right direction for third-party developer documentation. This is a Google Summer of Code project which will do enormous good for us.

And it’s not just the developer that needs a check-list – customers and users also use certification marks to inform their decisions – does this product work well with my existing software? So once the developer has finished, he wants to be able to point the customer to the mark on the webpage or on the box, and say “look – we respect all the best practices these guys say are required to behave well on the free software desktop”.

We need a certification process. This will grow out of good developer documentation, to some extent, but it’s more than that. Ideally, we would do what the Portland project is doing, and generate a test suite that a developer can run against his app to verify certain points – things like default shortcuts and file placements and management of WM hints.

And obviously, GNOME certification should include recommendations from Portland and LSB and freedesktop.org and ARC where appropriate.

So why does this count as marketing?

Because providing a GNOME certification program encourages adoption of GNOME. Preparing such a program will need us to think hard about what a GNOME application is, and think about the needs of the people developing GNOME applications. Finishing it will make it easier for people to write applications for our platform.

Marketing GNOME: third-party developers

gnome, guadec, marketing 1 Comment

Over the coming weeks in the run-up to GUADEC, I’ll be dumping my brains about some of the things I’d like to propose during the marketing BOF to develop the ideas I listed recently on marketing-list.

First up is third party developers (more colloquially, ISVs, but since most of our third-party developers don’t sell anything, that doesn’t seem appropriate).

Greg Kelleher from IBM told me that initiatives aimed at third party developers have three levels – high, medium and low touch.

  1. High touch is when the person meets a developer or trainer in person – interractive training sessions and workshops, or conference presentations fit here. This kind of interraction is the most beneficial for the recipient, but is a one-to-few effort.
  2. Medium touch is a rich, interractive experience without the human contact. Something like webcasts, conference videos and streaming, online seminars. These often provide the possibility for interraction, and allow a greater number of people to attend, with the loss of human contact.
  3. Low touch is our website and printed supports. API and interfaces documentation, tutorials, books, training manuals, archives of previous high and medium touch materials. This is passive learning – the developer comes to us to look for what he needs, spends as much or as little time as he wants, and leaves with no human interraction whatsoever. KDE has started an interesting initiative in the area, aiming to produce high quality distance learning paterials for a full QT/KDE course.

So – how are we doing now? Not as brutally badly as you might think – our core APIs are pretty well documented (with some notable exceptions), we are building up some tutorials, GGAD is still a great reference book, although it could do with a freshening up (like many of the tutorials, unless things have changed since the last time I looked), we stream and archive GUADEC presentations.

But we are not doing any high touch training, we’re not organising any web seminars, we’re not yet doing anything similar to OSDW. Even though we have lots of documentation, developer.gnome.org is missing a bunch of stuff it really should have (how hard is it to add a Google search-bar to the site?). In spite of our rich bindings, it’s hard to figure out how the API docs map to each of the languages.

Beyond that, we don’t sell GNOME books or developer kits on the website, and we haven’t really tried organising our third party developers to get them talking to each other.

So that’ll do for training & information diffusion. I haven’t even touched on application certification, which is a huge opportunity for us, as well as being enormously useful to third party developers.

SIGGRAPH

gimp, gnome, marketing 4 Comments

I can finally lift the veil on something that I’ve been involved with for a while now…

The Blender Foundation, the GNOME Foundation, the GIMP developers and the Uni-verse consortium have grouped together to hire and build a giant 20×30 island booth in the main aisle of the SIGGRAPH trade show in Boston in August. We had some help from an anonymous donor, and Ton has done a huge amount of work pulling all the strings together.

I’m really excited about this – SIGGRAPH is a huge show, and free software will be right in the middle of it – no more skulking in the corner of the “Open Source Exhibition” where the organisers hide the guys who can’t afford to be in the main hall and give then a 6×6 space to put up a computer – we have prime real estate.

I have all sorts of ideas about how GNOME and the GIMP can use this opportunity – from hob-nobbing with Hollywood types to showing off XGL, Cairo and all of the user interface work that people in the project have been doing.

I’ll be looking for volunteers over the next few weeks to halp with the stand – keep the dates in your mind when taking your Summer holidays – July 30th to August 3rd (exhibition from 1st to 3rd), Boston Convention and Exhibition Center.

Non-technical GNOMEys

gnome, guadec, marketing 3 Comments

There has been some debate recently on how the project can attract more people outside of the male geek group. Shaun McCance made the point that non-technical posts in general are typically under-represented in GNOME.

This echoes closely what Mitchell Baker has been saying about Mozilla:

[…] filling [non-technical] roles often means bringing in people who haven’t “come up through the project.” These folks who are new to the Mozilla project need to be accepted by the development community in order to be effective. Status as a Mozilla Corporation employee isn’t enough.

and

If one’s skillset is something other than code, then proving oneself through understanding the intricacies of our code is at best inefficient and probably a blocker for many people. So the challenges are to find mechanisms for people in non-code roles to demonstrate they share the values of the Mozilla project and can make contributions that people want to support.

Conclusion?

Integrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.

In other words: Be excellent to each other.

But more than that, we need to start recognising when there is a skills deficiency in the project, and actively recruit people with those skills, drawing them the map of how the project works, and helping them become great contributors. There are a number of examples of non-technical people coming into the project and making an impact – Quim Gil, John Williams, Telsa Gwynne – but there are probably more examples of people who passed close by, felt the water, and went on their merry way without ever engaging, or being engaged by, the GNOME community.

So during the marketing BOF at GUADEC this year, I would like to focus on this – how can we make non-technical people interested in marketing GNOME feel like their work makes a difference.

Marketing is not just promotion – real marketing is a two-way dialog between the project and the market, with us saying what we do and why, and the market telling us how we can do better, or what they need that we’re not doing. And GNOME marketers will feel like a part of the project from the moment where something we do changes the project for the better.

Next Entries »