I just wanted to say thank-you to the many GNOME developers and documenters who contributed their time and skills to helping us close an almost 10 year-old bug today. As I stated in the comment on the bug, I think work on developer.gnome.org should remain a work in progress. In this spirit, I hope more ideas and thoughts can be put towards this effort as we approach the Doc Sprint at the Developer Conference 2012 in Brno next month.
I am at the GNOME summit in Montréal. This morning Robert Ancell ran a discussion about GNOME strategy. The three main areas covered were:
1. What are we building?
2. Who is it for?
3. How do we get there?
The answers, of course, are multi-fold. We are building a desktop shell, applications, an active community, an ethos, a brand, a developer story, and an OS. There are side-effects to all this building such as libraries, middleware, stable API’s, and the emergence of a viable market and ecosystem.
Form factors (the form in which a consumer gets GNOME) include the traditional desktop, workstations, laptops, tablets, in-car systems, set tops and mobile devices.
GNOME is for enthusiasts, ourselves, family, friends, businesses, and in general, people. We discussed that it is still the case that GNOME tends to be in the domain of the technically savvy user. Our friends and family who use GNOME call us up for help. Occasionally it may take a couple of hours on the phone to sort out problems. Sometimes, they are ready to pack up their computer and hop on a bus or drive out to see us, even with easy to fix issues. Such trivial fixes are not obvious to a general user. It would be great if friends and family could depend on us less for technical support, and call us to talk about other things.
The effort put into localisation/internationisation and accessibility is put forth because it is important to us as a community that our product(s) can be used by all people. Meg Ford brought up an interesting point about the use of computer systems in businesses. If there is an employee who requires accessibilty features, the business is legally required to provide them and would want those features to be available in the system that is already used by the rest of the office. Therefore, it is important that our product can be accessible to as many people as possible.
At the moment, we seem to be reaching the enthusiasts, the people willing to take the time to download and install GNOME. A large percentage of the population will not do this.
So how DO we get there? Modules and tarballs…by delivering our modules and tarballs to distributions to pass on to the consumers.
Robert Ancell, re modules and tarballs: “There it is, that’s GNOME.”
Ryan Lortie: “We heart distributions.”
Can we change the strategy from being an application to being an OS, and then from OS to OEM (indirectly)? GNOME OS would be three things:
1. A set of minimum requirements we call GNOME. It includes the full package of vertical integration.
2. A nightly build.
3. Mobile reference build (for tablets).
I was new to being involved in this type of discussion within GNOME, which involved terminilogy that was new to me. These slides from a talk given by Rob McQueen at the Software Freedom Day in Boston (thanks Marina for pointing me to this) helped explain many of the concepts related to mobile devices running free software. I include it here for anyone else who may benefit.
What I learned and took away from this lively discussion is that we are building a set of complete yet modifiable products, not just a “box of bits” that others turn into products. It seems that the only way to get there is through hardware pre-installs. In order to accomplish this we need money and contributors. Contributions in the form of development, documentation, art, translation, community building and marketing will help GNOME reach more people with its products, ethos and brand.
I have been wanting to write Mallard docs for EOG for awhile, so
when I came across bug #633522, I decided now is as good time as any.
I committed an outline and some topic stubs yesterday.
$ git clone git://git.gnome.org/eog
$ cd eog/help/C; yelp $PWD/
to have a look at this outline. If you feel there are topics
that need to be covered that you do not see in the outline, feel free to
comment on the bug, and I will do my best to include them.