Marketing GNOME, part 2: Certification

3:36 pm gnome, guadec, marketing

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.

3 Responses

  1. Joe Tennies Says:

    Something else that would be good is a certification of HIG support.

    Personally, I think this is brilliant. I’d love to see a company do this and offer free certification for free software. Obviously, the free software would probably be lower priority, but it would be interesting.

  2. Juanjo Marin Says:

    I think that right now, the most attractive and accesible way to start to programming GNOME-friendly applications is using Mono. They have a lot of things that you mention: an IDE, documentation, an agenda, etc.

  3. RĂ©mi Cardona Says:

    The idea is very good, it can only bring quality to the desktop.

    Here’s a related idea though : why not use Gnome(-ish) apps as a test bed for this certification ? Several gnome applications (either official ones or unrelated to the gnome project) don’t fully respect these guidelines.

    gaim : uses dbus but not gconf
    epiphany : doesn’t use gnome-vfs

    While this may be a lot of work, it sounds worthwhile.

    Some smaller modifications were done through GnomeGoals (GOption, proper i18n in configure scripts). Why not extend it to add support for other gnome libraries?