I put the finishing touches on the second release of one of my open-source projects, Moo, last night. I'd been updating the documentation for a few weeks now to get that in sync with all the code changes that have been taking place. Now that it's finally done, I've released Moo v2.0 up to the Maven central repository.

Moo v2.0 is the first release that was driven more from requests made by users of Moo than for my own needs. If you're using Moo and you'd like to make a request, get in touch over email, twitter, or GitHub, and I'll see what I can do.

For those of you already using Moo, I'd love to hear some thoughts about how Moo v2.0 works for you and what enhancements you still need.

If you're not using Moo, it's a relatively unintrusive way of mapping one object graph to another in Java. Check out the website, the release notes or the wiki to learn more.

Ars Technica's "Google's Iron Grip on Android: Controlling open source by any means necessary" is an interesting look at some of the problems that Google faces with Android and some of the strategies they've had to employ along the way.

Google has had to take a very interesting position with Android because they didn't really want to be in the mobile phone business, they just want to protect themselves from the Mobile business changing the business they are in too drastically. Google's business depends on the health of the web, and Google's place in that.

In order to protect their position, Google doesn't want to rely too heavily on the goodwill of others, any more than Apple does, although I don't think that's as ingrained in Google's DNA as Apple's. Android, for Google, is about ensuring that they have a say in the evolution of the mobile phone and mobile device market and how that has an impact on Google. They were willing to give away a fair amount of value in this new market as long as it helped to support Google's existing business.

Exerting enough control over an open-source project to meet your own objectives is a tricky thing, and Android has always had to walk that line carefully by being a hybrid of open and closed source models. Much of the development of new versions of Android is done completely in the dark, with code only being open-sourced near the release date. Portions of the overall Android experience are wholly dependent on proprietary closed-source Google applications and services which are only available to you if you meet certain conditions. You can build an Android device without these, but not without a significant investment in filling these holes.

The emergence of out-and-out-forks that do exactly that has encouraged Google to continue to seek more leverage over the Android ecosystem by moving features into closed-source applications and tying them to Google services, which they can control more completely.

Ars Technica has done a typically solid job of covering those problems and some of the solutions Google has employed, and it's a worthwhile read.

I released v0.3 of my Tunnel Boring Machine (site, github, rubygems) this morning. The primary change you'd notice as a user is a simpler way to configure aliases for targets. There's a little more going on under the covers, and you can read my release notes if you feel so inclined.

Yesterday, I released v1.2.0 of Prune, which you can install and use as a Ruby gem, if you are so inclined. My updated summary of Prune says:

Prune is designed to maintain a file tree, pruning files by removing and archiving them when necessary.

Prune came from my own need when working with a project that made nightly backups. I wanted to retain the most recent two weeks of backups, retain the Friday backups for anytime older than two weeks within the current and previous month, archive all friday backups from months earlier than the current and previous months, and remove non-friday backups older than two weeks.

I'm still using prune with the same client project for the same purpose, it's going strong. This latest release was primarily around configurability -- I wanted to cut down on the verbosity of the output for my nightly batch pruning without affecting its utility as an interactive command-line application. Prune is much more configurable and much easier to configure than it was in release v1.1.1. You can read the full release notes on the blog.

There's nothing pressing for me in candidate releases for v1.3.0 and v2.0 that I've been tracking in github. There are things I'd like to get to, but nothing that I need. As a result, if you're using prune, or you'd like to, but you'd like a feature to be added, now's a good time to suggest it.

I've just released Moo v1.3 with extensive new support for updating a graph of nested objects including collections. This allowed me to get rid of a class we were using in a production to manage the nested update, using Moo to update each sub-object, but not the graph as a whole. This has long felt like a weak area of Moo, and that class felt like a piece of code whose existence personified features that Moo should and couldn't do.  As a result, I'm glad to see that class go away.

Moo is a project of mine for doing translation and update of objects from objects. While I encourage you to find a way to avoid needing to do this kind of data copying, if you can't avoid it altogether then I believe you'll find that Moo is a relatively unintrusive and yet reasonably powerful way to do these kinds of translations and updates.

I've also had a chance to flesh out the User Guide, add Release History and Community and Support pages to the wiki, and update the Moo website.  You can get Moo from the github downloads page or from Maven Central repository.