Candidacy (Michael Meeks)



Name:  Michael Meeks
Email: michael ximian com
Affil: Ximian Inc.

--- 73 word summary ---

	Lots of experience of Gnome both technicaly and relationaly, I
continue to promote Gnome widely at conferences and to companies.

	We must finance and encourage small interest group meetings as
well as GUADEC to increase real contact time.

	We need to bifurcate the project - the core environment and
the applications built on top of it, so we can release core
improvements more quickly, with a stable API, yet rapidly innovate in
the applications.

--- The longer version ---

	My qualifications and interest in Gnome are primarily as a
hacker. In that role, for the last months, I have been focusing on
Gnome 2.0, porting libraries, trying to resolve conflict and keep us
on track for a timely release. Secondarily, I am very interested in PR
and have enjoyed representing Gnome (and presenting all your hard
work) in various capacities to many audiences at various conferences /
LUGs around the world during the year, both in an 'inspirational
overview' format, but also as a technical tutor. I am however
concerned about several issues that affect our community and it's
future:

	The Gnome team needs to beef up its solidarity, and generate a
coherent vision, so we all know where we are going and can program at
full speed, unencumbered by doubts, or fears of re-invention due to
NIH.

	To address the coherency, I think we need to ensure that small
interest groups meet up much more regularly. This would build trust
and allow real communication - IRC is a slow, inflectionless medium.
Once we have funds to be dispersed - sponsorship of such meetings
would be a priority; along with encouraging corporate sponsorship of
locations and accomodation.

	I also believe we need to split Gnome into what people think
of as 'The Desktop' - WM, Panel, Nautilus, Control Center, Session
management etc. from the higher level applications and infastructure;
Evolution, gal, Gnumeric, AbiWord, gnome-print, etc. 'The Desktop'
should release regularly and be bound by firmer binary compatibility
constraints, and the higher level apps should be free to release
independantly and rapidly develop their neccessary infastructures.

	Duplication of effort must be avoided, we have to co-operate
more - have an inclusive approach to developing and incorporating new
technologies, and ensure that Gnome as a whole doesn't contain
incoherent and conflicting APIs. Conversely we need to be able to
ensure that neccessary features are folded back into underlying
libraries. Finaly and most importantly, we should avoid developing
new, untested APIs when we can fold working, tested code down the
dependency stack.

	And lastly, - this is a subliminal message - Gnome 2.0 is
really going to rock you should fork your modules now and start
porting ... right now.

	While some of the above issues may seem to be technical ones -
beyond the scope of the foundation - I think it is vital to have a
good grasp of them, and a close involvement with the people that
really contribute in order to be able to plan and guide the future of
Gnome.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]