[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My analysis of things
From: |
Nolan Darilek |
Subject: |
My analysis of things |
Date: |
Wed, 09 Jun 2010 09:44:58 -0500 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
OK, first, a disclaimer.
I'm not on anyone's "side" in this. I just want to see a standardized,
stable speech solution in the GNOME3 timeframe. Just who produces that
is immaterial to me.
In any case, here are a few points that jumped out at me from recent mail.
Brailcom seems to state that they don't (or haven't, until recently) had
the time/funding to promise much effort to this project. I can respect
this motivation. Also, to quote from Jan's email:
- ---
around the OpenTTS project did not speed up anything in this matter. The
project from which the development of Speech Dispatcher is currently being
financed was approved in the end of December last year, we just had to wait
for signing the contract with the Government of the Czech Republic and then
of course wait for the financial funds themselves.
- ---
So, according to Brailcom, long-term project development needs funding
and a core group of sustained developers to maintain.
Yet, based on what I've just quoted, speech-dispatcher development was
held up for 5+ months because the government hasn't yet signed a
contract promising funding. That's most of a GNOME/Ubuntu release cycle.
By way of comparison, we're seeing radical shifts in desktop design and
entire new Linux distribution versions in the time it takes Brailcom to
secure what it needs to continue a single project of relatively small
scope. That isn't meant to belittle, but in the grand scheme of things,
a speech subsystem isn't as grand as a GNOME shell or web browser, all
of which we need to keep accessible even as they change.
I understand and agree with the statement that our world is
unfortunately money-based, and we need money to survive. But whether or
not I agree with the statements regarding a long-term, core, paid
developer team, the reality is that it simply doesn't seem to be working
here, regardless of how much anyone might wish that it would.
Reality is that gnome-speech is gone, and if we pin our hopes on the
government, then we may very well not have a stable replacement in the
GNOME3 timeframe. I was using speech-dispatcher for years when its Pulse
support was buggy, even while every other application I used at that
time performed mostly nicely, and my request(s) to this list for a fix
didn't manifest more than a few replies. Then some volunteers stepped up
and provided one that, as of now, has worked mostly nicely. SD still
crashes, but instead of multiple crashes in the course of typing a
single email (that's no exaggeration, I promise you) I'm down to one
every week or more.
Like it or not, volunteers have stepped forth and delivered what
Brailcom couldn't. That isn't meant as a slam on Brailcom. I work on a
number of accessibility projects myself (an Android screen reader, an
accessible GPS navigation solution) and wish that I could deliver on all
the things I'd like to.
Yet I'm a volunteer, and while I don't doubt that I'm respected, reality
isn't dictated by philosophy. Rather, it's dictated by the facts, and
the facts would seem to me that the OpenTTS team has stepped forth and
delivered.
Anyhow, it really isn't my desire to be inflamatory. As far as I'm
concerned, there will be a working speech solution for GNOME3, and I
don't much care whether that is Speech-dispatcher or OpenTTS. However,
if the desire is to move the projects forward as one then here are a few
suggestions. Note that I made at least one of these almost a year ago
when SD switched to git because I worried, based on Brailcom's use of
CVS and the inactivity in said repository that development might not be
as fast as is necessary. Maybe now this suggestion will have more weight.
First, set up infrastructure such that contributors have write access to
the standard git repository. Don't make contributors set up their own
unofficial repository and place them in a lower class of developers than
are those of Brailcom, but let them contribute to the main one, using
the same policies as Brailcom's team and on equal footing. As far as I
know, Brailcom developers can join with OpenTTS and become equal
contributors, but is the reverse true? If not, then I don't see how the
two projects can join. There are a number of services and apps that make
this doable:
* http://gitorious.org
* http://github.com
* Gitolite: This would let you host the repo yourself, but grant
fine-grained commit access. Let contributors commit to scratch branches
rather than master, for instance, and merge those branches into the core.
Set up governance processes and ways for *everyone* to see what is
happening with development. Supposedly, the patches contributed in the
unofficial repositories were of low quality according to
Speech-dispatcher core committers, but I don't recall seeing said
discussions here, and low quality or not, the version shipped with
Ubuntu is lightyears ahead of the one I've used for years previously.
Governance practices could include:
* Contribution policies
* Code review policies and infrastructure: ReviewBoard and other apps
exist to help with this.
I understand that time and funding is limited. Perhaps Brailcom's
highest priority for said allocations should be in opening up their
development processes such that outside members can shape
Speech-dispatcher's future direction. People clearly *want* to
contribute, which is why the fork happened and sees active development,
but the reality is that we (speaking as a member of the GNOME a11y-using
community, not as an OpenTTS user which I'm not anyway) need change
faster than Brailcom and your government can deliver it.
In closing, I'd recommend this free book:
http://producingoss.com/
More specifically, this chapter on open source and money:
http://producingoss.com/en/money.html
And even more specifically, these sections. This one, "Appear as many,
not as one":
http://producingoss.com/en/appear-as-many.html
Or this one on committers:
http://producingoss.com/en/committers.html
Finally, and most important, here's one on projects, the involvement of
money and the importance of following project guidelines universally to
create a sense of solidarity between paid and unpaid developers. I think
this may be a huge cause of frustration here:
http://producingoss.com/en/money-vs-love.html
Thanks for reading.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwPqOkACgkQIaMjFWMehWJEOACeK2CsYLCV54RE44YiyaxbtsZh
obcAniRY+4aQLLgTlOX3gaDLPbftQSL+
=rlNA
-----END PGP SIGNATURE-----
- My analysis of things,
Nolan Darilek <=