Hey @Michael_Speth, thanks for the suggestions!
Weāre currently getting our ducks in a row on open sourcing various components of the stack. Itās always a struggle to balance documentation with active development, and we want to be sure the quality bar is high for our first release. Iāll be working this sprint on prepping Adapt for release, and look forward to any feedback on the framework.
As for tools, weāve made a good amount of progress there, which Iām happy to share.
For source control, weāre using github. Weāll be opening up individual repos as we think theyāre ready for public consumption. We know that if itās perfect, we waited way too long, so weāre trying to balance that urge with the desire to release our cool shiz to the community.
For project management, after experimenting with a couple different platforms, we settled on Jira about a month ago, and have managed our last two sprints (as well as arbitrary internal tasks) with it. Iāve used it professionally a number of times in the past, and thereās really nothing better. āIndustry standardā is the term that comes to mind. It has a number of integration points with Github (though, admittedly, bitbucket integrations are better).
For CI, weāre using Jenkins. Itās not the flashiest of tools, but itās lightweight enough that we can run a RasPI as a slave for on-device integration tests and metrics collection. Thatās been a massive boon.
For each of these tools, weāre evaluating how we open up the relevant portions to the public; Mycroft is a company, and weāre using these tools for the company as well as the project. The general public should absolutely see the pull requests on our init scripts, but not necessarily the jira issues related to getting VPN tokens shipped to devs.
As for the use of 3rd party closed source libraries, I think there may be a terminology kerfuffle brewing. The proprietary services that have been discussed for development purposes are publicly (and mostly freely) available web services from various providers. As we do not have access to the source or the binaries for those services, we cannot distribute them. We can, however, distribute client libraries (mostly thin wrappers over an HTTP client like urllib) and will be doing so. We are currently using a library for remote speech recognition named, aptly, SpeechRecognition. When we have our own speech backend, we intend to extend this library, allowing all consumers of the library to consume Mycroftās speech services easily, and to also allow Mycroft users/devices to easily switch between speech recognition providers. When faced with hard questions like this, my instinct is to go to the spec (or in this case, the GPLv3 docs on gnu.org), and the spec seems pretty clear on the subject. Please note that link is for the AGPLv3 license, a stricter version of GPLv3 that attempts close the loopholes around client/server boundaries and responsibilities therein.
#iamnotalawyerbutiwatchfranklinandbash
Speech recognition is a hard problem, and weāre looking for any help we can get from the community to drive this initiative forward. Please subscribe to OpenSTT, and point any qualified friends in the right direction! Specifically, people with experience with Kaldi, Spinx, or other ASR toolkits are welcome, as well as anyone with experience feeding temporal signal data (like audio or video) into various deep learning toolkits.
There is a moon, and we are shooting for it.
#killallthemoons