I get the impression at times that people think there are a myriad of
people paid to work on these issues. The reality is that there has
only ever been 1 person paid to work on Edubuntu/LTSP, and in fact
that person has been moved to another project for his paid time and is
now volunteering like the rest of us to work on Edubuntu. We had a
period of time where the primary developers of Edubuntu were basically
inactive due to real life situations. I know I personally feel like
I've let the community down by not being around for Hardy, but I have
real life obligations I can't just shirk to work on software. These
are the times when we need people from the user community to step up
and maybe try to contribute a bit here and there. I'm somewhat
frantically trying to get Intrepid ready for release and Scott
Balneaves sounds like he's able to help out more with LTSP bugs. We're
planning on having an LTSP Bug Day next week (looks like Wednesday) in
#edubuntu and could use all the help we can get (testing, triage,
patches, etc.).

---------8<-------snip------

Thanks for your note, Jordan. It is true
that a positive, pro-active, and constructive direction needs to be
assumed. I am not sure that paid staff is the key to success or the
reason for failure. The 'only one person is getting paid' case was
made last year during the Feisty debacle.

I imagine that most people on this list are trying Edubuntu not
because they are paid to but because they heard about it and decided to
give it a go. I doubt there are many job descriptions calling for
this. We all do it because we care. I personally run a non-profit, at
great personal cost, to advance the adoption of FOSS in Hawaii. It's
not because I'm getting paid.

Understanding the dynamics of this community, and those behind the
successes and failures of Skolelinux and the K12LTSP, is the key to our
success. You may or may not realize, for instance, that Fedora started
because Warren was fed up with our work helping schools with FOSS
because he felt that there was not enough customization and tools to
make it teacher-friendly. Years later Fedora + RedHat + Eric Harrison
and Jim McQuillan equaled the K12LTSP.

The culture of the RedHat sponsored K12OSN mailing list was such
that Bugs and Experiences could be reported on the mailing list, and
fixes and patches were created. Because users saw Eric H or Jim M
actively engaging the community, with Aloha, the community responded
with feedback, support, help, etc. No one was told to come to IRC if
they wanted satisfaction, to file a bug if they wanted it fixed, or to
buy a support contract from Red Hat if they needed help.

The culture of the debian-edu mailing list is one of momentum and
organization. I have bugzilla reports, end-user questions, and
packaging discussions all arrive in my mailbox. Skolelinux has
certainly benefitted from government sponsorship, but, the philosophy
and intent have been Focused on a distro requiring one hour or less of
support each week by an average teacher. With this goal in mind, there
is a reason to respond to all mailing list queries.

A bug squashing on IRC next week sounds good. If I have submitted
bugs to the mailing list but cannot make the IRC meeting, is it still
my responsibility to handle this bug? Is there a process for known
bugs to be addressed whether they come from the list or Launchpad?

All the pieces are in place. I'd like to think that there is
nothing but good will amongst the communities of users and developers.
A little vision and follow-through is all we lack.