I can’t express how happy I am that I have the privilege of having a combination of time, ability, desire, and energy to contribute substantially to the Diaspora project right now. Ever since I started using it in the spring it’s something I’ve wanted to be able to help with. I certainly got my feet wet back then on some tweaks to the Twitter and Facebook interaction code, the latter of which is permamently broken thanks to Facebook’s new API spec. With the amount of getting up to speed on Ruby, Rails, and the Diaspora code base I’m looking forward to helping tackle a much larger and persistently requested piece of code: a Diaspora API. There’s already been a good amount of ground work done on the API by previous contributors, namely Frank Rousseau on the API and Kent Shikama on the authentication piece. While there is a good base there is still a ways to go. When I look at some of the things we are talking about doing it seems like the API is almost a prerequisite. That is separate from things like better supporting mobile apps and the like (besides as wrapping the mobile site). So while there are several big features that can be contributed to this seems like the most important lowest hanging fruit to me. I figure there are a few steps that I need to move forward on before really cranking out code on this feature.
First, because this is an API I think it’s important to be able to test this during development in something approximating a production environment. Yes the CI system in GitHub helps with that immensely, but for interactive tests and that sort of thing I think a production-ish server is important. While I’ve established a development environment with server before I haven’t done a production one. This is a great opportunity for me to do that and to properly bridge my dev server VM to my host NIC card and do device level testing. That can also help with some other features that seem to be on the horizon potentially, like making the S3 bucket feature more universally applicable outside of Amazon S3 systems.
Second, because there is an existing code base for me to work from I need to become familiar with it. There are nuances of implementation that has already been discussed and I need to properly assimilate that. I need to get familiar with where things are as of now and then do an initial small implementation and confirm my development workflows. Once that’s established I can begin doing some of the heavy lifting.
Third, because this is a big piece of code I want to make sure that this development effort is being properly communicated and coordinated with the Diaspora core team. We’ve already begun laying out how we want to do that but that’s something that will require constant refinement as time goes on so that it doesn’t become too disconnected but at the same time doesn’t become too overbearing or a nuisance.
In case my social media posts or blog posts don’t express it enough, I’m incredibly stoked to be being able to help this project in this way. I’m hoping this is the beginning of a lot of my personal development energy towards this project and towards more open source contributions in general.