12 Contributions, 12 Months

 


A few years ago, a friend of mine decided to challenge himself to do 12 patches to Drupal in 12 months.

Since I work on an open source product, I make contributions to OSS practically daily, but this year I'd like to give back a little more - so I'm going to attempt to do 12 contributions outside of the things I work on daily.

But why?

It's worth spending some time thinking and writing about the current problems with open source software. We have, by and large, a demographics problem, a problem with large corporations hoovering up the unpaid labour of contributors and profiting off it, there are various cultural issues within the free and open source communities we're still trying to address.

And yet, I still think of Open Source software as being something of a triumph in a world where we seem to value profit over everything else. Where we seem to, almost reflexively, seek to reduce any occurring phenomenon to its dollar value.
From the first time I heard of Free and Open Source software, I was inspired by the fact that here was an instance of the kind of best instincts in humans - being creative and productive purely for the sake of creativity and productivity. Of course, the cynic will say that it's all egoboo, but I don't buy that.

I really should write about all this in more depth, I suppose - this isn't a particularly well thought out piece, I just wanted to gesture towards why I love (and have practically always worked in) open source.

More practically, I'm hoping that these contributions will both be useful for others, and teach me some new things.

Comments

Post a Comment

Popular posts from this blog

JCE's Gifted and Talented Center

Image
Back in South Africa, in the early 90s, I was invited to take part in programmes offered at the Johannesburg College of Education's "Gifted and Talented Center". I can barely remember much about it. I recall that I did courses in electronics, drama, programming, and study techniques. Further, I remember the buildings and the general feeling of the place (massive buildings, alcoves with chairs and windows in the long passages between primary blocks, etc.). However, I couldn't remember very much around the nature of the programme (if, indeed, I ever knew anything about it) - who funded it, how were pupils identified, etc. I tried searching online but to no avail, there was one hit on someone's personal blog, but that was it. I did, however, manage to find the director of the JCE Gifted Child Enrichment Center from the time I attended and took a chance, asking him if he'd be willing to provide me with some information. He response was both generous and massively
Read more

100 Go Mistakes: 1-9

So I'm pretty much looking for a place to write up notes on things I'm reading - which, right now, includes Teiva Harsanyi's "100 Go Mistakes and How to Avoid Them" (does anyone else get confused when writing title-case? Let me look up the rules quick ).   Anyway, I'm at a point where I want to write down some of what I'm learning so I can refer back to it later, so let's go. 1 - Unintended variable shadowing Go's short variable declaration operator (:=) can introduce unintended effects if you're making use of it within nested blocks. Here's a simple example . The workaround is really to explicitly assign the value to the variable declared in the outer scope, either by using temporary variables when using the declaration operator, or simply assigning directly. 2 - Unnecessary nested code This provides a fairly useful heuristic with regards to code complexity. Essentially, Harsanyi wants us to try, as far as possible, to keep the "happ
Read more

100 Go Mistakes 10-16

Here we go through the rest of Chapter 2  10 - Not being aware of the possible problems with type embedding Go allows you to not only include types as fields in structs, but also to embed them. Essentially this makes the fields of the embedded/base type part of the "containers" interface. Harsanyi points out that this can lead to exposing more than you might want to, since all of the base type's fields and behaviors are exposed as part of the container. If there is reason to hide the base struct's details, rather simply include it as an unexported field and write accessors. 11 - Not using the functional options pattern I'll admit that I hadn't heard about, or consciously noticed, this pattern before now, but it's quite brilliant. An issue with positional arguments in complex functions is that having tons of arguments that are either null, or unused along certain paths, etc. is a real PITA. My own preference, when factoring out the functionality into mult
Read more