A non technical perspective on GNOME goals and future work

[Daniel Veillard <veillard redhat com>]

  Foreword: this is a personal view point and carries no approval
            of any sort from the board or anybody except me. Both
	    talks from Miguel and Havoc at Guadec were optimistic,
	    and there is good reasons to be optimistic about the
	    GNOME project future. The document below just sums up a
	    number of non-technical issues which were raised to me
	    during Guadec and the advisory meeting. They are just
	    input of discussion and an attempt to see what solutions
	    we can use to speed up the adoption of GNOME.



     A non technical perspective on GNOME goals and future work
     ==========================================================

			   Daniel Veillard
			 veillard redhat com
			     April 9 2001

  GNOME need to reach new users to sustain its growth, the goal
is to get a large enough user base to be an interesting development
platform for the ISV. There is a few directions we need to look at
in order to expand to new users:

   - fix the internationalization (I18N) and localization (L10N)
     problems. The first problem is a lack of good support in the
     Gnome framework, unfortunately it is not a good use of resources
     to try to patch the 1.X framework, the best we can do is get
     2.0 rolled out as soon as possible and make sure through serious
     testing that it actually works without problems. One of the
     unsolved problem in this area is having a set of decent fonts for
     X-Window which covers the full Unicode set. The L10N work
     has too sides, tools and people. Getting better tools seems a 
     urgent problem, the current framework is sligthly broken, and
     don't provide the effective diff informations to help the
     translators do their job efficiently; looking at the KDE tools
     seems a good idea. Getting more translators is a 2 step process,
     first avoid loosing them by giving them time and tools to do their
     work in a reasonable fashion and second grow the regional Gnome
     communities, the idea of having a European and Asian GNOME foundations
     is a first step to organize our project regionally.

   - make sure that GNOME is adequate for the new portable devices,
     this include framebuffer support but the main problem is to
     make sure that using GNOME on machine with limitation is a
     sensible thing to do (this should have some synergy with the
     work on accessibility and usability).

   - interoperate with other environments both on the Unix desktop
     (KDE, Java, ...) and outside. One of the key point is make
     the use of the GNOME development platform in a different context
     and the integration of tools developped in other frameworks
     provides a decent user experience. Basically the goal is to
     convince ISV that they can consider their target platform
     to be the Unix desktop independantly of their development platform,
     hence increasing the potential user base to the sum of the 
     users of the various desktop initiatives. In practice, sharing
     default settings, look and feel and documentation are the first
     things to work on. Trying to share data formats, making bridges
     or reusing common layers are the next steps.
 
  Note that these steps will not only benefits new users but also existing
ones. Solving a number of those points will improve the user experience.
It is also clear that since GNOME is starting to be used in large scale
corporate environments we can benefits from some of their experience in
areas where GNOME had little support:

   - usability, getting serious usability test done started for the 1.4
     release. Getting the interface intuitive and polished takes a lot
     of time, moreover this work affects final applications, it can get
     some help at the toolkit level but ultimately all GNOME applications
     should go through this process. What we can hope is to get a set of
     guidelines as the result of the usability testing on the set of main
     application and get those widely distributed and explained to the
     application developpers.

   - accessability, this is usually considered a very specific area but
     it ain't so. Though the initial goal is to support users with
     disabilities, it practically matters to every user. Everybody
     experienced cases where one has limited functionnalities, either
     physical (being stuck in a small airplane seat where typing or using
     the mouse is difficult) or material (when using a small screen or
     a palm like application with slow input speed). Again the review
     process done for the main GNOME applications should be used to generate 
     guideline, a lot of support can be added at the widget level too
     for supporting accessibility needs, but it is usually not sufficient.
 
  We also need to grew our developper pool, without good programmers there
is no good applications. The work needed in this area is well known, the
technical user community is the majority of the GNOME user base, and 
the developpers are the core group of people who got interested in the
early stage. Moreover large companies are joining the project, they can
potentially provide a huge workforce but getting them to contribute 
effectively and quickly have the same requirements than non-corporate
programmers:

   - keeping the platform stable. This is not an excuse for not fixing
     bugs but keeping the compatibility of our interfaces (API and ABI)
     are critical. GNOME doesn't have enough momentum to be in a position
     to loose confidence of even a fraction of the developpers using it.
     Clearly getting GNOME-2.0 deployed fast is important too, we need to 
     provide early on transition guideline (and possibly tools) to ease
     the transition of applications to the new platform.

   - providing complete and accurate documentation. The fist step is
     to get and check that the GNOME code is completely commented to allow
     API extraction by gtk-doc. The libraries also need more general
     programming instructions including examples. Those two parts of the
     docummentation should always be available. It is now clear that the
     documentation project is switching to Docbook/XML and that we should
     get an unified way of producing and accessing the documentation. Most
     of this framework is also likely to be shared with other project
     like KDE.
  
  Last but not least, we need to improve communication both within the
community, with our users and with the outside world. The needs and the
work needed covers a number of different areas:

   - more frequent venues to get the developpers to talk (and hack)
     together. So far the feedback on both GUADECs is that this GNOME
     only conference is tremendously useful. It improves communication
     between people, get personal issues solved around talk and beers,
     and give a sense of the overall directions the people want to work on.
     The main drawback is that this format is relatively costy, in term of
     money to get everybody on the same spot, in term of work needed to
     organize it, and also in term of resources taken away from the
     companies the people work for. So keeping them a yearly venue sounds
     the current best choice. Hence the direction is to create smaller
     GNOME meetings, more focused geographically and technically. There
     is already 3 events currently planned before GUADEC-3 next year 
     (Usenix, ExpoLinux, OLS).

   - sharing technical problems, public debate of issues and allowing
     dissent to be recorded. As GNOME transitionned from a pool of 
     hackers working on their free time to an even larger team most of
     which works for companies where GNOME is a stategic part of the
     technical framework, the temptation of doing design quicker by
     keeping it mostly private is hard to avoid. However, it is clear
     that to become a piece of the GNOME infrastructure, the design of
     a substantive software part must be done in public. The goal is to
     keep the community of developpers aware of what's going on, gather
     input from a larger set and allow the pros and cons of choices in
     the technical design to be discussed. Reaching consensus is a hard
     process and not always possible. We should try to get it anyway and
     at the minimum always allow dissent to be voiced and recorded in
     mailing list archives. Ultimately the GNOME board of director can
     be called to resolve a conflict. This is very important to continue
     to work as a single entity. If we fragment, the result is likely
     to be the same as for the previous Unix desktop war of the 90's:
     irrelevance.

   - communicating with our users uses 3 mediums, static documentation,
     our web site and mailing-lists. Getting up-to-date user documentation
     is always a burden, we should make sure that at least all applications
     shipped with the GNOME release have some in english, getting it
     translated requires major efforts. The best we can do there is to
     help giving good tools to create, translate and use this documentation.
     The next step is our web site, it is currently redesigned, hopefully
     contributing new content or fixing existing one will be made easier
     than the current version, simplicity is a feature in this area.
     Mailing lists are the last stage in the integration of a user within
     the GNOME community. It is not an easy step, and as an intermediate
     providing good archives of the lists with searching capabilities on
     our web site is an important step to help user learning about and
     getting involved with GNOME.

   - general communications mostly involves PR, press contacts, and 
     presentation of GNOME at public events. Our communication group is
     a crucial part of this effort, it is getting organized and we are
     far better in this area than one year ago. However we should not
     rely on this sole group to handle everything, one important point
     is to get organized locally to handle events. Going to show
     more than a few times a year can get very boring, so getting some
     structures organized geographically to cover local event and sharing
     this work is an important step. I hope that building and European
     and Asian GNOME foundations will help getting this structure done.

  My conclusion is that we are starting to get organized as a relatively
large and complex project. We must now select the axis where efforts should
be focused to grow our user base. This lists a number of them, and offers
opportunities for contributing to the project even if your are not
a programmer. I will be extremely happy if after next year Guadec I
can look at this list and find that half of the issues raised now have
been fixed, I believe so because this project is incredibly dynamic !

Daniel Veillard

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/