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!
|
]]>
