Amit's Fluffware


Over the years, an assortment of self-made pieces of software have accumulated on my disks. This collection (mostly python scripts and modules) sort of grew up from scripts I wrote at home for various tasks, some adapted out of stuff I did for work, maybe even some left over from my University days. In their current state they are not usable software projects. However, they contain working solutions to common problems, ideas for future projects, tricks and other stuff that could be very useful to other people.

Generally, I strongly believe in "upstream" (find a project that does something close to what you want, extend it, and send a patch). However, it turns out that most of this stuff remains private. Some of my (and I believe many others') reasons for not publishing stuff are:

As you can see, this does not generally make things unpublishable. It just means that they need (a little) more work. More work means time, and we usually have more important (i.e. higher on our personal priority list) things to fill it (sometimes this means writing more such stuff). So - this just accumulates and you never find the time to make it publishable.

First thing to do is to overcome two psychological hurdles:

What's the plan?

  1. Avoid calling this stuff "software" invent another term. Here goes:

    Pieces of source code in patchy/non workable state, that someone accumulated for personal use and decided to make public. You shouldn't expect it to work or be well designed. Instead, it's possible uses: read and find out how certain things can be done, paste interesting bits into your own code, use as base/pilot code for new projects/new contributions to existing ones.
    This should make people treat this properly and help overcome the "patchy code" argument argument mentioned above for not sharing.

  2. Prepare and share a repository, as early as possible.

  3. Start pushing files in. To minimize time & work - they would be in 'raw' state - i.e.: only processing done should be 'deprivatization'.

  4. The initial 'deprivatization' itself should be fast and dumb-headed. Just replace stuff with a recognizable constant string, such as XXXXX.

  5. The above procedure, and the interdependencies of the fluffware would probably make them unusable. This is expected and even desired - it would later force me to focus on the more patchy and unmodular parts.

  6. Try making the repository open for public check-ins. This way other people might help some of the work, maybe even add some of their on fluffware.

  7. Add some 'table of contents'. This file should have an entry for each seperate "fluffball" (a functionality of some fluffware which is either already implemented as a seperate module/program or planned to be seperated out as such), listing the files in which it is implemented, and containing a short (one line) description of the development plan for it.

  8. After (and in parallel to) checking in files, start working on making them reach 'usable' stage - this would most likely include adding support for configuration and parameters, plus removing unneeded dependencies. At this stage I should also probably add some license/copyright statements to avoid possible trouble in future.

  9. Once in a while, when some major fluffball reach usability, make a release (so people can download a stable tarball without the need to set up a revision control system).

  10. A second 'next-generation' branch should be added to the repository. Development on this branch should focus on reimplementations (i.e. to use new versions of external publicly), redesign, and preperations for making stuff usable for sending as "upstream patch".

Current situation

It's more or less in the middle of stage 6 stated above. I've made a repository publicly available for reading, and checked in some "deprivatized" stuff. Currently, for technical reasons, it's read-only.

However, I made sure to choose a distributed source-control-system (GNU arch/tla) - this means that anyone can create local mirror and work on their own branch (which could be merged back later). Of course they can always also just mail me changesets

Next (very urgent) stage, is preparing the contents file. It should be done checked in during next week.

OK - Now go on and read the tla instructions, so you can start digging into some messy raw fluff.
By Amit Aronovitch,