Let me quickly fill you in on how Github forks and pull requests work. Imagine we go with the public Github project, and are down the road a little ways and have released something. If somebody out in the community is excited about it and wants to help out by, say, fixing a couple of bugs, then they can find our public project and fork the repository. This basically means that they have their own copy of the source code and can make whatever changes to it they want without affecting the original. So they can fork the repo and check in a bug fix. Then they can submit a pull request back to the original project. We would be notified, would be able to review their changes, have some dialog if we want any further tweaks, and when it's all set, accept the pull request, propagating their changes back into the master repository. If a particular developer is involved enough that we want to give them direct access to the original master repository (like we will all have), we can do that. This is how pretty much everybody these days maintains ownership of their code base, but also allows the community to contribute with minimal friction.
That, in my mind, is the key benefit to making this project open source. Another benefit is that, if publicly available, our project could serve as reference code for people wanting to implement their own apps against the Leaguevine APIs, which I think is also in line with the mission of this project, and would make Uncle Mark happy :)
The drawbacks to making it open source are, obviously, that it's not secret, so somebody could take the code and use it to make their own competing app, or deploy it to their own servers as a carbon copy or something. But really, who would do that?
The other wrinkle here is that we would not want to publicly expose our client secret for accessing the Leaguevine APIs, but there are a few ways to solve that, depending on the architecture of our app and our deployment. Getting technical here for a second, so if you don't care about this level of detail, please just take my word that it's totally solvable :) If it is only the client (Javascript, mobile app, etc.) that accesses the API, then it's all user-driver authentication and we don't need to store a client secret anywhere and there's no problem. If we need to access the API server-side, then we can either inject the client secret "manually" at deployment time (keep it in deployment scripts that we don't check in, or require that it be set in the environment, etc.) and not have the client secret checked in anywhere, or we can create a separate configuration repository that is private and contains any sensitive secrets like the client secret, and have the deployment process pull it down at the same time as it pull down the main project repo and inject it that way. Or I suppose we could create a private repo that just contains our deployment scripts along with the sensitive secrets and do it that way.
Anyway, bottom line is that I don't think there are any significant drawbacks to open sourcing it, unless you are worried about people "stealing" the code, and there are a couple of pretty substantial benefits.
B