Developer Catchup: Docker 1.1.0, Rust 0.11.0, Python 2.7.8 and Dropbox Go Libraries

developercatchupDocker 1.1.0: The first post 1.0 update for Docker is in and Docker 1.1.0 now has a .dockerignore mechanism for ignoring file changes, containers that now pause when a commit it happening (rather than messing them up), container log tailing, the ability to feed tar archives to docker build and other changes which should make life a bit easier and more predictable.

Rust 0.11.0: The latest Rust announcement for version 0.11.0 is about smoothing out the type system to allow for dynamically sized types and refactoring the standard libraries to allow for that. It means that language embedded elements like ~ and @ have become library types called Box and Gc that should make the language easier to understand. It all brings Rust 1.0 closer – by the end of the year is the current hope.

Python Updates: The start of July saw a Python update for various security issues – Python 2.7.8 updated the OpenSSL library, fixed mimetypes and UNC paths regressions and blocked an arbitrary code execution hole in CGIHTTPServer. There were also a number of core and library fixes detailed in the release notes. There was no corresponding update for Python 3.x though the CGIHTTPServer issue is scheduled to be fixed in Python 3.4.2 according to the in progress changelog.

Dropbox Go: Dropbox, a big Python user, has also been working with Go and has been moving its infrastructure to Go based code. In the process, they’ve written a lot of libraries to support that work and now they are open sourcing those Go libraries with a 3 clause BSD license. There’s code for caching, an improved error interface, a programmatic SQL statement builder, a memcahce client library, connection management and a space efficient hash library. And they will be doing it the right way – they’ve committed to using the public versions of the libraries inhouse (rather than maintain their own branch). You’ll find the documentation for all the libraries over at Godoc.org.

Open source is a development process too

csavatrar2
A recent report suggests that Microsoft may open source its M# language upon its as-yet-to-be determined release date. M# is a language being developed in tandem with Midori, a research operating system Microsoft is also developing and, apparently has been developing since 2008. In many ways this plan to open source on release is an excellent demonstration of a classic misunderstanding of open source and the audiences for open source. When Microsoft people talk about releasing M# and open sourcing it, it strikes me that the company still doesn’t get open source as a development process and still sees open source as a deliverable, as something you do to clear some check boxes or unlock a market.

The “open source as a deliverable” approach is a perfectly valid way of creating an open source software if you assume that for the thing to catch on it needs to be ready to roll. This can be because you perceive the people who will use the code as predominantly end users rather than developers because you are making software for them to use in the form of, say, an application. If you believe that at release, end users will begin using the application, and that as a secondary effect, developers with a specific interest or other motivation use the open source code as an opportunity to develop and contribute, and, all going well, the project will develop momentum, then yes, it is a valid way of open sourcing a project.

But that doesn’t hold true for development tools and languages; by definition your users will be developers, they are just not yet developing of your tool or your language. Every user is a potential developer for your project or a source of feedback on design. No user of tools is without an opinion on their tools or a desire to craft a better tool. If you go down the “open source deliverable” release path though you’ve already not made use of that resource and are sitting at version 1.0 having internalised all the development processes within your organisation. When the release does occur you’ll now have all your internal processes grinding against outside contributions.

It gets worse though as the longer you take to get to 1.0, the more established those internal processes are, the louder and harsher the grinding. And all of that is assuming developers even want to get on board the open sourced language or tool you’ve released – they can easily come to a conclusion that if you’ve made it to 1.0, plans for 2.0 are already nailed down and if developers want to do anything meaningful setting a direction for development, version 1.0 is more a flag for them to fork the code base and do their own thing.

For development tools and languages, open source isn’t just a way of delivering code to users and ticking a check box. At its most powerful, it’s the core of an open development process which creates an engaged ecosystem of developers and tunes your internal organisation to working with that ecosystem. “Release early…” is core to that process; developers understand that releasing an open source version 0.1 of something isn’t saying its is anywhere near complete but releasing a 0.1 does let people look in on what is being created and if your code, and associated documentation and writings, convey what you are planning in a compelling way, it will bring people onboard. And that will provide the seed for a meaningful open source development process.

Some might ask won’t opening the development process early like that disclose other proprietary plans that your organisation may have. The simple fact is that if your work is closely enmeshed with those plans such that it is visible in the code of your project, your project probably isn’t a good candidate for being open source anyway.

Be aware from the start that this doesn’t all work like magic and you will have to drive your vision forward with the project and actively engage with the outside developers and users, but that friction can be a powerful constructive friction in a process which can scale up over the time it takes to reach version 1.0. By the time you reach 1.0, you will already have a community of developers around your project… and that’s far more potent than just dropping an open source deliverable at release.

It’s probably too late for Microsoft’s M# to benefit from this approach, but if you are planning on creating a open source tool or language or something else aimed at a development audience, remember to open your development process too.

Lime editor, HBase 96, Font Awesome and MOON LASERS – Snippets

Snippets

  • Lime text editor: People love the Sublime Text editor. But being closed source does set some folks worrying. Some of them do something about it though, such as “quarnster” who has been creating Lime as an open source version of Sublime Text. Built with a combination of Go 1.1, Python3, Oniguruma and optional Qt5, Lime still has plenty to implement, including compatibility with Sublime’s Python API, keybindings and snippets, TextMate Snippits and getting solid cross platform support. But if you are looking for a project to work on…
  • HBase 96 arrives: The Hadoop-based “big data” database, HBase has been updated to HBase 0.96 with around 2000 issues closed and lots of contributed work. This included getting the MTTR (Mean-time-to-recovery) down to under a minute, support for snapshotting tables then moving and restoring snapshots, Cygwin-free native support on Windows, more efficient compacting, a switch to Google’s ProtocolBufffers (in part for futureproofing) and much more. There’s also a bunch of incompatible changes so do check the notes. Find the release and the release notes on the Apache Software Foundations pages.
  • Font Awesome 4.0: A font of icons? Yes, the rather spiffy Font Awesome is back with an even more awesome version 4.0, now with 370 icons in a single collection. Designed for Bootstrap 3.0.0, styled with CSS and free for commercial use. Check out the sample page and examples. And yes, you can use it without Bootstrap too.
  • And finally: NASA just announced they have got a 622Mbps download rate from the Lunar Laser Communication Demonstration. It’s asymmetric though… 20Mbps upload, but hey, to the Moon.