Don’t Be an Open Source Douchebag

I love open source software. It provides both a neat training ground for programmers, a good place to go scratch that itch. On the other side of things, it provides awesome software for people, including some software that would never come out of a big development house.

Still, there are some issues with free software that don’t really show up to the same degree with commercial software. One such thing is documentation. It’s painfully obvious that documentation is written by people who:

  1. Already know the software in and out.
  2. Don’t like writing documentation.
  3. Know nothing about how people learn.

For instance, when I started a side project a few months back, I was looking for a build system. After settling on CMake, I set about trying to make sense of it. There’s the ever-present getting started example, of course. And then there’s the full reference of everything you could possibly want (almost).

But in between those, there’s nothing. Well, nothing except a book, which just goes to show you that there’s something missing — a professional writer could obviously make some money out of explaining things in a reasonable way.

The problem with this is that it doesn’t match how people learn. Getting started is a good step, but a relatively small one. Most of the time will be spent incrementally expanding the knowledge, moving from beginner to expert. Most time will thus be spend in some kind of zone in between the “getting started” and “reference of everything” levels.

Worse than that, some open source programmers have a tendency to view their full reference documentation as an appropriate resource for everyone. “It’s all in there,” right? But pointing a beginner at a 40-page document detailing all the options of some application when all they want is to run it properly isn’t very helpful. I’m sure you know what I’m talking about if you’ve ever used an open source command line tool.

That ends us up with the really dark side of free software culture. The true douchebags out there will not only be extremely smartass in their RTFM comments, they’ll also be incredibly sensitive and defensive about the software they’re working on.

I ran into a problem with cygwin’s SSHD implementation last week. In searching for the solution, I found this mail list answer:

  Wrong.  That is uninformed speculation and guesswork.  Stop
spreading misinformation.

  Cygwin SSHD has had the support for fully logging in as any
user since 1.7, as you have already been told and completely
ignored.  Go and read the manual.  The link was in the previous
email I sent in this thread.

  freesshd works exactly as Cygwin *used* to before it got
subauth support: when you log in with a key, rather than a
password, you just end up as an admin user.

Wow. This kind of answer is wrong on so many levels. First of all, while he makes it seem like the functionality has been there forever, cygwin 1.7 is still not even out of beta. The chance that an end user has it is about 0. So, with the current version (1.5),  supposedly cygwin sshd works just like freesshd. This is clearly false, because the original poster reports one working and the other not (which is, by the way, exactly the same results that I had).

So, a user reporting a problem about logging in gets pointed to a long documentation about security settings in a beta version, doesn’t understand a word from that document (no surprise there), and as a result gets told to “stop spreading misinformation”. Truth is, simply installed like any normal user installs applications, one works and the other doesn’t, something made quite clear by an answer from the original poster in a different place in the thread:

> Are you talking about password or public key authentication?
> If the latter, Have you tried the LSA authentication package
> in Cygwin 1.7?
I don't know. I'll try to deciper that. Sounds complicated. In
the meantime, friend is using freesshd.

The essence of what he’s saying (which has been completely missed by the cygwin developers) is that the effort required to get cygwin to work like one would reasonably expect of it is much higher than the effort required to just google for something that just works out of the box. The fact that you could potentially make it work is irrelevant, because he’s not getting any help actually making it work.

He might as well just have said, “I don’t care about making it work for you. It works for me.”

Software companies usually compensate for their complete lack of useful technical support with a good (or at least reasonably decent) amount of help documentation. Free software usually has neither.

I encourage any programmer to practice their technical skills on an open source project. But while you do so, take the opportunity to practice your people skills a bit as well, or why not your writing skills? Don’t be an open source douchebag — someone reporting your software’s flaws is not attacking you personally.

What’s a Good Final Year Project?

Here’s a question from the mailbag, coming from a student doing games programming at a university, gearing up for his final-year project:

The degree I’m doing currently has been very much centered around graphical programming, aswell as using various programming languages to bolster our CV’s I would imagine. We’ve not really touched on networking, or AI at all. Our main language in graphical programming has been OpenGL too, we’ve dabbled with DirectX a little, mostly managed directX with XNA.

As a programmer already in the industry, could you give me any advice on the type, and level of project I should aim for, for it to be a suitable demo project to show to prospective employers? It’s difficult enough as students to find our way into the games industry; if we don’t know what employers want, or what is considered worthy in the eyes of the employer, it lowers our odds tenfold.

In a way, the answer to the question depends on what kind of position you’re trying for. I’ll try to answer with regards to as many positions as I know.

For starters, is graphics programming what you want to be doing? If it is, things like what graphics APIs you know become a lot more important. From what I know, most games studios that do windows game development have gravitated towards DirectX. With that in mind, having done a large(ish) project on DirectX could definitely be a plus. If all other things are equal, I’d definitely go for learning DirectX.

Not having experience with networking or AI isn’t all that much of an issue, unless you imagine going specifically for a networking or AI programming position (and even then, it’s more of a bonus than a requirement). One thing is clear however… if you’re looking to get into professional development at a large studio, you should be going for C++.

Now if we look past the technical requirements, there are a few things that can be said about such a project in itself. What you get from a good project is a nice entry into your demo reel — something to show off. This has a few implications, but most importantly something I’ve touched on before, in A Spectacular Failure: your project is going to be judged on emotional first impressions, not how technologically advanced it is or how nicely coded it is.

Your number one enemy is over-scoping the project, ending up with something that does lots of things, but does none of them in a great way. Come up with a good core gameplay for the game, and then polish it to a great shine. Fix all those annoying glitches and bugs, make sure everything looks as impressive as possible. It doesn’t need to be rocket science, as long as it’s well executed. In the end, what a games studio is looking for is a programmer who knows how to finish projects in a good way.

That doesn’t mean your project should be Space Invaders, but in general trying for something too big is more of a problem than overdoing something too small.

Finally, as an entry on your demo reel, make sure you make the game available in an easy manner. Have a page with plenty of screen shots, videos and preferably the game itself easily downloadable. Your coding ability will definitely be tested with some form of work sample as you apply to studios, so the code itself being available is less important. Reading code is hard, so it’s unlikely that someone will have time to read yours. However, having a finished game to show off is worth a lot, as is the experience of going through all the phases in finishing a game.

Other posts you may find interesting, relating to getting into the games industry and getting started with games:

WordPress Themes