Linux Voice

This month I've been working on processing large volumes of data. I won't bore you with the details, but it involved using a tool that brought some data together, then pushed it up into a commercial cloud infrastructure so we could process it on lots of machines at the same time. The tools have proved to be a bit flaky, but with one important difference: The tool I was using to pre-process the data and get it into the cloud infrastructure was open source, whereas the tools in the cloud infrastructure were closed (at least the bits we had trouble with were).

There are lots of reasons to use open source software, but a huge one for me is that I can fix stuff. When the open source tool broke, I would look at the code. Sometimes I could fix the problems, sometimes I could work around them, but at least there was something I could do. When the closed source software broke, I was stuck waiting for a customer service agent to get to my email and see if they could do something.

Now, either of these things is a bit of a lottery. It's possible that the bug in the open source program is in some byzantine code that I can't understand let alone fix, and it's possible to get a quick fix from customer service agents. However, my small amount of anecdotal evidence is starting to convince me that neither of these are very often the case. I've frequently been able to fix little issues with FOSS software, and battled endlessly with customer service people. I thought about this when reading Mike's piece on FOSS advocacy this month. For me, advocacy always starts with understanding why something's important to you, and using that passion to explain your point of view to someone else.

It's not all about other people this month. You can find out what Andrew discovered when he ventured out of Yorkshire to a little estate called Bletchley Park, discover the latest software with Graham's FOSSPicks, write your own graphical programs with Mike's guide to Python, and much more. Spring is here, so turn the page and dive into a pool of Linux learning.

– Ben Everard

Andrew Gregory

Graham Morrison

Mike Saunders