[Opentts-dev] merging opentts and speechd was Re: Fwd: Re: OpenTTS 0.1 released.

[Luke Yelavich]

Greetings everyone.
I am somewhat saddened to see this discussion come up again in the way it has. 
Whilst my announcement went out to several lists, I shall reply to both the 
opentts-dev and speechd lists, to reach out to both communities. I appreciate 
everybody who has participated so far keeping it from being  a public slanging 
match, because at the end of the day, none of us want this for either project. 
One could argue that the more we are back and forth in the public eye about 
something so important as text to speech, the more the general user base may 
very well lose faith in what is trying to be achieved.

As to the discussion at hand, I don't intend to repeat what has already been 
said by the Speech Dispatcher and OpenTTS community. I agree with the points 
that have been put forward, but at the same time, I do sincerely hope we can 
come to an agreement about the way forward. I am still saddened about the fork, 
and I certainly don't deny we, the community members who went ahead with a 
Speech Dispatcher fork, could have done things better, either in working out an 
agreement with Brailcom, or made our work more readily available for Brailcom 
to consider for future inclusion in Speech Dispatcher. We went ahead with the 
fork, because at the time, it was felt that a lot of work was still to be done, 
and a development process was needed that was rapid, colaborative, and made 
important work needed by text to speech users available as soon as it was 
considered viable and stable. Even then, the fork didn't officially take form 
until the community tried to negociate with Brailcom 3 times, in 3 open 
letters. These letters discussed the future of Speech Dispatcher development, 
and a development model that would allow Speech Dispatcher to move forward, and 
do so as quickly as may be possible. I won't go into detail about that 
conversation here.

In addition, we neglected to put processes in place that would ensure all our 
work was sent to Brailcom for possible inclusion into Speech Dispatcher. Had we 
done so, it is possible that things may have turned out differently. As it is, 
this can be rectified, although it will be a lot of work, however if we do want 
to attempt to return to the one project, this must be done.

Then there was my announcement of the first release. I assumed, possibly 
incorrectly, that those people who read the announcement, were aware of the 
fork and why the fork was created. I also didn't give credit where credit was 
due, and am sorry for not doing so. The efforts of Brailcom with the Speech 
Dispatcher project, as well as the time that was invested in considering what 
would be needed longer term, in the form of the TTS API specification, 
certainly deserve to be credited, and praised. It certainly is thanks to their 
efforts that we are even able to offer a viable alternative, and possible 
standard text to speech framework, for the free software ecosystem today.

Thinking about the negociation that has been attempted so far, there are a 
couple of things that have caused the processes to fail. Firstly, the community 
behind the OpenTTS fork did not attempt to keep up contact and continue 
discussions after Brailcom reached out, and attempted to get the situation 
resolved, this is after the initial series of open letters from the community. 
Second, I think one side, and possibly both sides of the negociation, have been 
somewhat stubborn about what they wanted to see in the deal. I don't intend to 
point fingers, and I certainly discourage people doing so, or even talking to 
others out of public site as to who they feel are the individuals or people to 
blame. It is enough to know that one or more parties haven't come to the table 
with a certainty to resolve the issues at hand, even if it meant compromise.

Yes, compromise. That is one word that we have not yet seen used in these 
discussions. Even I am guilty of not considering compromise, and in doing so, 
have contributed to the failure of these negociations. It is easy to see such 
things in hinesight, but in doing so, I do regret not being willing to move 
from what I felt were the requirements for moving ahead as a coheasive and 
colaborative community with a common goal. Again however, compromise has to 
come from both sides, and in saying this, I do hope that Brailcom are willing 
to consider what we have put forward, even slightly. Jason made a good 
suggestion about how the development process could be managed. As the first 
part of compromise from the OpenTTS community, I'd ask that we all consider 
what Jason proposed, and attempt to flesh things out from there.

Jason's proposal, was the following, and I quote from his email:
> If you were to propose a governance structure for the project in which neither
> brailcom nor any other single organization could exercise control over
> development and release decisions, and in which leadership roles in the
> project were open to all contributors based on merit, I think it would attract
> stronger support from the OpenTTS development community.

As I've already said, I think this proposal is a good one, and one that ort to 
be seriously considered as one possible compromise. Hopefully, we will think of 
more, so that there are multiple options on the table.

In our negociations, I also hope that we can all agree on one thing, and I 
believe this is one point that is not so easily compromised. Large free 
software projects, with a lot of contributors, have always been developed 
rapidly. In 6 months, the GNOME community is able to churn out a new desktop 
release, with new features, important bug fixes, and plans for further 
development in the coming 6 months, or beyond that. Other desktop environments 
may not work on the same time scale, but are able to put out one or two 
releases a year, all with the same achievements. In short, free software 
desktop development is rapid, so rapid in fact that unless you are regularly 
watching some of the key decisions and processes of design and development, it 
is easy to miss them. If we as a community, want to provide a text to speech 
framework that can be delivered to, and used by end-users, we need to be able 
to keep up with developments elsewhere in the free software ecosystem. Sure, 
text to speech is not a big area, and not everybody will require all the 
functionality that text to speech has to offer, but as developers, we need to 
be confident that when a new use case comes up that requires text to speech, 
and does so in a way not yet required or explored by other developers or users, 
we can clearly state that we can deliver a solution to that use case as soon as 
may be possible, probably a few months. For this reason, we do need a release 
early, release often process, that encorporates current development and user 
requirements, planning ahead for further improvements/new technologies/use 
cases on the horizon, and providing some support for users of our 
existing/older releases for a determined period of time.

Just how we go about this process is what is up for discussion, but I do feel 
that if we want to be relevant in a few years time, and still be the speech 
framework that developers turn to for their text to speech needs, we need a 
model and process that is flexible, allowing for solutions to be developed and 
delivered as soon as possible, but still be stable enough for day to day use. 
The various free desktop environments have development models that for the most 
part work well. I think we should consider a model that is similar, and attempt 
to resolve matters, and allow for future quick development, with a good 
governance process that ensures no proposed patches go unreviewed, and only the 
cream of the crop get put into the working code tree.

Ok this whole email has been rather long and rambly, but I doo hope people get 
the gist of this mail. So please, lets keep calm, lets keep our arguments 
clear, and to the point, but most of all, lets work out a way forward, so we 
can work together, towards a common goal.

Kind regards
Luke Yelavich