If you've been around Second Life long enough, chances are you've come across a"Stargate(TM)". Based on the TV show of the same name, they are networked teleportation devices that take you to any other place where another stargate is. In my early days of SL, I was even friends with the creator of a Stargate network. The other day, I had gotten a copy of Doran Zemlja's "OpenGate", which is an open source Stargate network licensed under the GNU GPL. I had put up an OpenGate right at my store's front door, hopefully to help bring in more customers. Today I had an interesting idea: Why not make a triangular Stargate? It shouldn't be too hard to do.
Boy, was I wrong. I did make a simple prototype, no problem. But when I moved all the appropriate objects, textures and scripts over, the shape reverted to a regular gate. WTF? "Ok, no problem, just find the script the function call that reverts the shape, and comment it out". The only problem? ALL the scripts are virtually unreadable to a mortal's eyeballs. I complained about it on the OpenGate network group, and I was told to look on the OpenGate website for why Doran did this. What i found made absolutely no sense at all:
People who've looked at the source code in-world have noticed
that is pretty much unreadable. The first question I'm asked is
"why the obfuscated code?"
During development of the first gate network, I would often succumb
to the temptation of modifying the code in world to fix bugs. The
result was that the online tarball would become out of sync with
what was actually in use, and I lost much time scratching my head
over which version was correct. Obfuscating the in world code
forces me to do development out of world.
There is a fair amount of shared code between the different
scripts. On several occasions I found that I had different versions
of key algorithms in different scripts, and this caused many
headaches. To avoid this, I wanted to use C/C++ style #includes and
#define macros, and that necessitated moving to a development
platform with real development tools.
To some degree, obfuscated code is a natural result of using
#include and #define macros.
Often people would make changes on their objects and submit them
back to me for inclusion in the project. Such code had often gone
through several iterations of copying and pasting in different
tools, and it was often difficult to get a clean diff to figure out
what had changed.
Obfuscating the in world code should help reduce this problem. I
will no longer accept contributions that do not diff cleanly
against the code in the distribution.
Many well meaning
people who used the objects in world took them apart, picked a
single script, and found their favorite nit to pick in the name of
readability, efficiency, reduced memory, or reduced lag, and
"fixed" them. They often did this without understanding the
complete design, especially without understanding how the different
scripts interoperated with each other, how the different objects
interacted within a single gate, or how the individual gates
interacted with each other in the gate network as a whole. On a few
occasions this led to disruptions of the gate network. Now that the
distributed chord algorithm is in use, these problems are
magnified.
Obfuscating the in world code increases the level of effort
required to make changes, and should reduce the number of frivilous
unconsidered changes.
That last sentence and paragraph burned me up. She's obfuscating the code to actively discourage other people from making changes. While this doesn't technically violate the GPL's terms, it's actually a way of trying to be cute with it. Whenever I make a project, I always try to keep the code as neat and easily readable as possible, not just for me, but for anybody who wants to study it, modify it, and even sell their own modifications. That's the nature of the GPL at work. If Doran doesn't want other people to make changes and submit them for inclusion, she should have chosen a different license.
Yes, you read that last sentence right. It seems to me that Doran doesn't totally grok the GPL. A good GPL project doesn't put up obstacles to code changes, it removes as many as possible. So what can be done about a poor GPL project like this one?
Answer: Fork it and do it better!
|