Announcing the OpenTTS project, a fork of speech-dispatcher
cerha at brailcom.org
Wed Apr 28 13:35:58 UTC 2010
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.
> We repeatedly asked Brailcom for direction on this list and were told
> that they couldn't commit any resources to speech-dispatcher at this
> time. So, speech-dispatcher was becoming a more important project to
> the accessibility community, but the maintainers were not working on it,
> and they had no idea when they would be able to work on it again.
Not being able to promise is not the same as not having an idea.
> 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
> 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
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.
> 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 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.
More information about the Blinux-list