The most exciting move in Acquia for me so far just happened a few days ago. We rolled out what was called "Big tent" internally, and means much wider support for all Drupal 6 sites. As Dries points out in his blog post, we used to support our Acquia Drupal distribution via forums, tickets and phone support. However, we found that virtually all sites will use other modules, custom code and themes, tweaks to existing code. This was not surprising, but took some time to figure out how we could handle in our support organization.
While there are multiple exciting sides of this story, the one I am about to tell is about the openness of our approach to this move. The story on "making the Acquia Network Connector modules available separate to Acquia Drupal" quickly morphed into publishing them on drupal.org, since that made most sense.
Sometimes in conversations, we had problems explaining that Acquia Drupal is really only some open source components packaged together, and you can get most of them on drupal.org. There is nothing proprietary in there, and it is just built to help you start off with Drupal quickly. While our connector modules were open source all along, hosting them on drupal.org helps us get through our message even more naturally. And it would be foolish to just think about our messaging.
By hosting our module there, drupal.org helps us inform people not using Acquia Drupal that their module might be outdated. We don't need to duplicate that infrastructure and in fact can invest work into improving that (eg. help upgrade Drupal.org to Drupal 6, help fix project module issues), which benefit the whole community. The module also opens its issue queue to everyone who is trying the module out. This worked well with the open Acquia Marina theme (although admittedly that is much more general purpose then single-service connector modules are).
Hosting on Drupal.org also helps people scrutinize our source code and commits/changes with the usual tools they use for drupal.org, as well as use the same deployment and source code management strategies they employed for other modules. If we'd setup a public subversion repository for this module, we'd put more work on the site manager's shoulders when updates and changes come around.
All-in-all, while I have seen some negative voices about single-service connector modules being hosted "on community resources", especially, when using the particular service requires payment, I think our approach helps improve these community resources, as well as let site maintainers work with our service easier, which is a win-win result after all.
Similar service integration modules on drupal.org where payment is a requirement include CampaingMonitor, Workhabit's CDN2 Video, one of the two editions of Mollom, the recently announced Kaltura integration module and so on. There are also modules integrating with commercial products (where you'd buy a product instead of subscribing to a service) of course. Most of these can be found in the Third-party integration category on drupal.org.