Announcing the OpenTTS project, a fork of speech-dispatcher

[William Hubbs]

On Wed, Apr 28, 2010 at 03:35:58PM +0200, Tomas Cerha wrote:
> William Hubbs napsal(a):
> > There has, in my personal opinion, been very poor collaberation between
> > the accessibility community and Brailcom.
> 
> We announced that we are not currently able to put a reasonable amount of 
> work into it,
> but that we welcome anyone willing to help.  We avoided any unfair promises, 
> but offered
> collaboration.  Please, read the answer to the "Open letter" by Mr. Buchal 
> carefully.
> 
> We didn't receive any concrete offer for such collaboration.  So it can be 
> also said
> that there has been a poor collaboration between the community and Brailcom.  
> I don't
> think it's fair either way.
> 
> > One example, in my opinion, of poor collaberation has been Brailcom's
> > extremely minimal involvement in the development process.  A development
> > repository was opened by Luke so that some of us would be able to get
> > changes into speech-dispatcher.  Many patches were sent to this list,
> > for a long time, but there has been extremely minimal participation from
> > Brailcom, so the official repository was never updated and Brailcom
> > hasn't been responding to our patches.
> 
> We have put a huge amount of resources and our own personal effort into the 
> Speech
> Dispatcher project within the nearly 10 years of its development.  And among 
> other
> reasons also due to a minimal feedback from the community, we started to put 
> more of it
> into other our projects in the last two or three years.  As we have 
> responsibility for
> these other projects, we can not switch our long term plans from day to day 
> just because
> the community decides they now need us.  Thus we avoided making any promises 
> that we are
> not able to guarantee.  That's all.
 
I understand that you have other projects you work on, and you cannot
commit much time to speech dispatcher.

However, when the community did start adopting it, and sent multiple
patches to the list, there was still no response from you.  Not even a
message explaining that you did not have funding and would look over the
patches when you had time/funding IIRC.

> > Another concern I personally have is Brailcom's speechd-up project being
> > deprecated as well as their comments on their speechd-up project page
> > about speakup itself being replaced by other technologies.  On the
> > contrary, speakup has a very active user base and shows no signs of
> > being replaced.
> 
> We only announced that we are not going to continue speechd-up development.  
> We will be
> glad if someone else will take the project and go on.  That's the difference 
> compared to
> Speech Dispatcher.
 
 Quoting from http://www.freebsoft.org/speechd-up:

---------- cut here ----------
The aim of the (currently deprecated) Speechd-Up project was to give
users the possibility to use the Speakup screen reader with software
synthesis. It worked as an interface daemon between Speakup and Speech
Dispatcher, who took care of the software synthesis. 

The approach with providing console accessibility through special kernel
code however proved to be problematic in many aspects and given the
current developments in accessibility technologies, these tools have
been substituted by other means. 
---------- cut here ----------

Note the second paragraph.  Speakup is far from being replaced, and it
is still under development.  So, I  would say that this statement is
partly false.  Yes there are some issues, but those are being worked on,
and the kernel developers have been positive towards speakup
development.

> > In my opinion, the fork happened because of poor collaberation and slow
> > responsiveness from the maintainers.
> > 
> > I understand that what Brailcom spends their time on is controled by
> > funding, but they made no effort or very minimal effort to work with the
> > community.
> 
> As well as the community made a little effort to help us.  No one asked, hey, 
> I would
> like to see a new release because I feel the feature XY deserves it.  What 
> can I do to
> help that happen?  We were only asked to act or make public promises.
 
 If you do not have the funding to do releases, why not figure out a way
 to share this responsibility with the community?

> > Yes, we could continue doing unofficial releases and waiting for them to
> > do official releases when they get funding, etc, but the problem there
> > is that if we add functionality in the community releases, there is no
> > guarantee that that functionality would be accepted by Brailcom in their
> > official releases.
> 
> I wouldn't see anything wrong about having unofficial patches in Speech 
> Dispatcher
> packages.  That's the packager's responsibility.  Of course, it is more 
> convenient when
> the patches get included upstream, but let's not exaggerate the situation.  
> We said we
> are going to include them and we were working on it as the time permitted us. 
>  We
> announced the existence of these unofficial versions in the meantime.
 
 I think the concern is since gnome/orca is planning on getting rid
 of gnome-speech in gnome 3, there will be a larger user base for speech
 dispatcher and bugs will need to be fixed and new releases will need to
 happen much more often than they have so far.

Unofficial patches are fine for short-term fixes until a new release
gets done, but that's all.

> > I personally would be open to working on speech dispatcher, but there
> > would need to be a big change in the way Brailcom collaberates with the
> > community for me to be comfortable with that.
> 
> If you really mean it, if you are able to accept the increased overhead of 
> collaboration
> which is compensated by avoiding duplication and confusion, let's stop 
> fruitless
> discussions.  I understand your reasons and if you try to understand ours 
> pragmatically,
> there is still a chance for more collaboration.  I am stopping any arguments 
> on this
> topic right now because it is really wasting time.  Please, consider our 
> limited
> possibilities and try to suggest a model that would suit you.
 
 Personally, I feel that having a separate official and development
 repository is also duplication of effort.  Since you do not work on
 this project full time, Are you willing to allow community members to
 commit directly to your repository on freebsoft.org?  I do not know of
 any open source projects that have a separate repository for
 "development" and an official repository.

What about faster response for releases?  How can you share the
responsibility for release management with the community?

 William