Why was this posted on Slashdot anyway. They may call programmers rude, but this is clearly a case to RTFM before asking.
Probably because there are a *LOT* of people, many of them Slashdot readers, who don't understand what the GPL actually does, because they go off of all the weird touchy-feely "spirit of" misinterpretations rather than reading the text of it themselves.
This post serves as an excellent illustration of the surprises some naive developers can get when they make this mistake, and as a caution for other developers that have the same naÃve misunderstandings.
In other words, this is an education campaign for the readers of Slashdot.
Software is part creativity (e.g. design, architecture, misc problem solving) and part busy work (e.g. filling out methods and entering domain table data). Some people are better at one part or the other.
Personally, I find that the busy work part is straight forward and easy, requiring no brain thought, but is also boring and unmotivating. To do it, I just have to buckle down and start filling things out line by line, data point by data point, method by method, taking frequent 5 minute breaks of doing something fun to keep from getting burnt.
The creativity part can be tougher. When there are problems to be solved and the creativity stops, what do you do?
The first thing I do on *any* project is break it into a bunch of modules, and then break those modules into their components, and so on. I can then outline the behavior of each piece, and usually that is enough. Like I learned form "What About Bob?", baby steps often helps.
Sometimes, however, (or often, if you are me) a problem will need real thought. The problem is complex and the solution isn't a straight forward application of the design patterns you already know. It can take a lot of creativity to work through these. In cases where I feel stuck, there are a few things that often do the trick for me:
1. I find *someone* to talk it over with. The more they know how to code, the better. That being said, often just having to explain the problem to anyone that will listen will be enough to clarify what the problem really is, and the solution will dawn on you.
2. In the complete absence of a willing participant (and if you feel stupid describing it to a teddy bear), write out an outline of the *complete* problem, and a first stab of how you might be able to solve it. Then write what is wrong with it. Repeat.
3. Sometimes the issue is that you are in a stale environment. I've had times where I sit at my desk all day and can't get anywhere on a problem and cut out early from frustration, just to find that the solution comes to me while driving home listening to news radio. In other words, sometimes going for a drive or a walk--some place where you can change environment and relax and think about nothing--is enough to make you think.
Always draw your curves, then plot your reading.