Free Software Needs Free Tools :: Benjamin Mako Hill

Over the last decade, free software developers have been repeatedly tempted by development tools that offer the ability to build free software more efficiently or powerfully.

The only cost, we are told, is that the tools themselves are nonfree or run as network services with code we cannot see, copy, or run ourselves. In their decisions to use these tools and services -- services such as BitKeeper, SourceForge, Google Code and GitHub -- free software developers have made "ends-justify-the-means" decisions that trade away the freedom of both their developer communities and their users. These decisions to embrace nonfree and private development tools undermine our credibility in advocating for software freedom and compromise our freedom, and that of our users, in ways that we should reject.

This is a good point, and one that I think deserves some scrutiny. The open source KForge project provides an opportunity to escape hosts like SourceForge, Google Code, GitHub and Bitbucket, but it is relatively difficult to deploy on commodity hosting. (This week I had the opportunity to talk to someone who had deployed it.) I'm guilty of storing many of my scientific projects on Google Code and Bitbucket, but one of my main projects is hosted privately on a server I pay for, using only Free Software.

One of the issues I see with scientific programming endeavors is that often the self-hosting option presents some red tape, whereas the hosted option is much simpler and easier -- particularly if the project itself is cross-institutional. This is one of the reasons I pushed for our primary simulation platform to be hosted at Google Code, rather than on a local, university-hosted server.

Nicholas Piël » ZeroMQ an introduction

ZeroMQ is a messaging library, which allows you to design a complex communication system without much effort. It has been wrestling with how to effectively describe itself in the recent years. In the beginning it was introduced as ‘messaging middleware’ later they moved to ‘TCP on steroids’ and right now it is a ‘new layer on the networking stack’.

IPython's moving to 0MQ for their client/server model. Some elements of yt likely will as well -- specifically the remote push/pull of updated image buffers for the remote pan-n-scan.

Tagged 0mq code python

Chromium Blog: A sneak peek at the Native Client SDK

Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.

This is really, really cool. My understanding is that the sandboxing is the hardest part of this.

Tagged chrome code

GSoC folks, read this: (Re: Lightweight copies/renames)

The real challenge of GSoC is not coding, it's learning to work with a community. And the first lesson is: communicate in public

An amazing discussion not only of Google Summer of Code, but of Open Source development in general by Matt Mackall, kernel hacker and project lead of mercurial. Developers on the yt project are in general pretty good about this kind of thing, but there are some aspects of the development process (and I am a culprit here too) that could use improvement along these lines.

Tagged code opensource yt

NASA Modeling Guru: Effective Scientific Modeling: A Software Engineering Perspective: Trusting the Software

Most science models that I have worked with have extremely little formal testing associated with their development and maintenance.   In the more sophisticated models some form of full-system testing is done with some degree of regularity or automation.  Even then, the automated full-system tests are limited to "it ran to completion", "it got the same results as yesterday", and "the results are identical on varying numbers of processors".    As a consequence bugs are often discovered long after they are introduced and are typically more difficult to fix as the offending piece of code is less familiar and perhaps more solidly "embedded" in the source.

Tagged code science