And on the twelfth day of coding, my project gave to me

• 12 Users Moaning
• 11 Program Pipelines
• 10 Brand New Warnings
• 9 Inner Platforms
• 8 bytes-per-pointer
• 7 Sorts-of-Sorting
• 6 Bugs-a-Hiding
• 5 Privilege Rings
• 4 Abstractions
• 3 way merges
• 2 Underscores
• And a Makefile in my Git Tree.

There are a lot of free software projects out there, and you'll likely want to contribute to at least one of them. It might be in the form of a good bug report, a fix for a bug, some documentation, a new feature, translation to another natural language, or something else. There are numerous forms of contributions, and they're all valuable and necessary.

A contribution may be a quick, one-time thing, or a long-term committment to the project. Both are good. Free software thrives on drive-by patch submissions, but of course some people need to participate in each project more or less permanently.

As a very important point, note that you do not need to be an expert to contribute. Nobody cares if you have a PhD or not, as long as you make things better. Even if it is only a teeny, tiny little spelling mistake, it's almost always welcomed.

There are some things to keep in mind though, for things to go well.

• First of all, be polite. Don't show up on the project mailing list telling everyone how stupid they are for not having fixed this problem already.
• As part of being polite, be patient. Don't push, don't nag. Many high-visibility free software projects are developed by people who are very busy people, and it may take a while for them to have time for you. You don't need to wait forever, but give people some reasonable time to respond before pinging them.
• Talk to the project developers to make sure they welcome your contribution. If you're going to be making a large change, do this before starting work. For example, rewriting the Linux kernel in Python turned out to be something Linus wouldn't accept, whereas fixing a segmentation fault in gcc is always welcome.
• As the first part of your contribution, explain why you think it's a good idea. Explain the bug, or why a missing feature is needed, or whatever it might be. This allows others to understand your motivation and hopefully gets them into the right frame of mind.
• Be prepared for negative feedback. It's possible that the way you've done things isn't acceptable to the project, for some reason. It might be stylistic, or perhaps they can see a better way to design things, or maybe they can see a mistake you've done and want you to fix that. You'll need to adapt your changes based on feedback. That's OK, that's how peer review works. If you're convinced the feedback you get is wrong, you can argue against it, but do it politely.
• License your changes the same way the project already does.
• If the project has contribution guidelines or paths, follow them. These usually exist in large projects, such as the Linux kernel. Smaller projects tend to be more flexible.

Some related reading:

• http://libregraphicsworld.org/blog/entry/contributing-to-free-software-projects
• http://kegel.com/academy/opensource.html
• http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-to-software-projects/
• http://www.shlomifish.org/philosophy/computers/open-source/how-to-start-contributing/

The Unix operating system was originally created in the early 1970s. Apart from a number of technical innovations it made, or brought together, its develoment has been driven by an ethos often named "the Unix philosophy". While this wasn't explicitly written down by the original developers, there are various formulations. Perhaps the most succinct one is by Doug McIlroy:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Others have expanded on this, up to and including writing books on the topic. See the Wikipedia article for some discussion and references.

This philosophy is clearly present in, and clearly drove the development of, the older parts of Unix, such as the most basic command line utilities and how they are used together. For example, instead of having each program that produces output have an option to sort the output, the sorting is put into its own program, and the two programs can then be combined together into a pipeline.

The ethos has waned in later years, due to factors such as the move to graphical user interfaces and desktop environments, and the proliferation of the kinds of data we now deal with. GUI applications are not so easy to combine together as command line filters: it doesn't seem like anyone's designed a system where that works well. The kinds of data now processed are often not textual, and are instead graphics, audio, video, or structured documents using a markup language.

However if you use, or program for, a Unix system then it is good to be aware of the philosophy. It will help you understand why things are the way they are.

This series of articles (The Truisms) is aimed at imparting some of the things we find to hold true no matter the project one undertakes in the space carved out by our interests in Open Source and Free Software engineering. We will be posting them interspersed with other articles over time.

When we started the yakking blog, Lars, Richard and I decided that we wanted to build a resource to help newcomers to the world of open source. To help those who are interested in using Open Source and Free software to develop yet more free software. We started with a set of requirements we had for what we wanted to achieve and while those requirements have developed over time to include supporting those who simply want to use free software to achieve other ends (such as simply being productive in their otherwise unrelated jobs) we always know why we're yakking.

This is a critical part of any project (or indeed any activity you undertake at any time). Put simply, if you have no reason to do something, why bother to do it at all? Oftentimes we do things for which we think we have "no reason" only to discover, when we stop to think about it, that we do have a reason - no matter how spurious or facetious it might seem at first.

If we were slightly more formal, we might say that you should do nothing unless you have a well defined requirement for it and a well understood criterion on which to assess whether or not you have met the requirement. However in the world of writing code because it's fun, there need be no more complex a requirement than "I fancy doing it". For example, a few years ago I wrote a full implementation of regular expressions in pure Lua "for fun" because I wanted to better understand how deterministic finite automata can be used to parse text.

So, a little homework for you: Whatever you're doing over the next few days, take a moment to think about why you're doing it and how you'll know if you've achieved that goal.

From time to time you will need to transfer files between computers. You will probably, for example, publish release tar archives, or transfer log files for debugging to another computer. There are a variety of ways of doing this, and you may need to choose the one to use depending on circumstances.

• rsync is good when you have already transferred one version of a file or directory tree, and need to transfer updates. It is quite remarkably efficient at that. It requires to be installed on the other end.
• sftp and scp, which are provided by ssh, are good for transfers across untrusted networks (i.e., any network except your own, and even that may be suspect).
• nc (netcat) can be a good thing, on a trusted network, for transferring data as quickly as possible, since it is doesn't do any encryption. Despite this, it doesn't require transferring a password in cleartext. nc can be combined with tar or cpio to transfer more than one file at a time.

You probably want to avoid, if at all possible, the following:

• ftp is completely unencrypted (including sending your password in cleartext), and often difficult to get through firewalls.
• rcp, which is like scp, but is completely insecure. Luckily, it is rarely even installed, except as an alias for scp.

Example

Let's assume we are in a directory that we want to transfer to another computer, other.example.com, as the directory /tmp/foo on the remote computer. Here are a few ways to do the transfer:

Rsync and scp are equally simple:

rsync -r . other.example.com:/tmp/foo/.
scp -r . other.example.com:/tmp/foo/.

With Rsync, you may want to consider more options as well, such as --delete, to make sure any extra files on the target end get deleted. If you do that, then also test it with --dry-run.

Netcat requires a bit more setup. On the remote end, you'd run it like this:

nc -l -p 12765 | tar -xf -

On the local (sending) end, you run it like this:

tar -cf . | nc localhost 12765

Note that there are at least two versions of nc out there, with incompatible command line syntaxes. This example uses the syntax from the version in the Debian netcat-openbsd package.

You can send from the remote end to the local end as well, and you can choose which end connects and which end listens, depending on the situation. For example, if your remote end has a firewall that prevents it from listening, you'd listen on your local end instead.

(But, remember, only do this if your network is trusted. Otherwise someone can get the file instead.)