Showing posts with label programing. Show all posts
Showing posts with label programing. Show all posts

Saturday, March 23, 2013

Fork Games!

Today I want to talk about a controversial word in the free software community, Fork!

Most software projects don't really need forks.  How many word processors, web browsers, cd burners etc do you need?  Probably one or two is more than enough.  But when it comes to games, gamers tend to collect hundreds to thousands of games given enough time.  They at least try them out to see how they play.  I tend to play one or two things for a long time and get all I can out of it, but over time I have played quite a few different games starting back when I was a kid. 

Proprietary game companies frequently come out with a game, and make more and more sequels of this great game.  Gamers like this because they know if they liked the first one, the next one will be similar so they will be more likely to buy then next one.  Thus you have popular series such as Ultima, Final Fantasy, Heroes of Might and Magic, Super Mario etc. 

Free software projects on the hand, are afraid of the Fork! If there is game one in the successful free software games, one of two things will happen.  The original team will keep trying to improve it, not just mantain it so it continues to run on newer computers (like when libraries get out of date) So eventually with all the new features it will play like a different game.  (example, crossfire, battle for wesnoth) Or even if it doesn't play different, it will look significantly different and have features and game balance changes the original did not have.

On the other hand, they often just abandon it, so it get forks, multiple forks, many of these forks don't even work on the platform the game originally worked on, and then there is the question of what is the real fork if people didn't change the project name. (IVAN, also known as iter vehehims. ad neccam)

The other problem with free software games is the dead projects that don't compile and run and never did.  Well, maybe they compiled on one person's system at some point, but no one else can get it to work, and the original developer cannot be contacted.  You can find a lot of this type of project on any popular free and open source software hosting site.  While this is not a problem in and of itself, you keep wondering if perhaps the original developer should have forked a project that already worked properly and changed a few things, if they might not have a better game that people would actually care about and play.


In my next post, I will propose an alternate universe where free software game development thrives and surpasses proprietary  game development using the fork.

Monday, February 05, 2007

The Myth of Meritocracy

Some people like to work on open source projects. They seem to think it is a meritocracy and they will get to work for people who are much more skilled, nicer, and less full of themselves then their bosses at their corporate job. However, these issues are not going to go away in the open source world, or anywhere else for that matter. Perhaps a simple explanation is an order, so people can quit having unrealistic expectations for how things are supposed to work.


First of all, people have to understand why successful projects are started and what kind of person tries to start a project. Doesn't it seem easier to work on something that is already being started? If you actually have some skill, then yes, because people want you to volunteer to work on their project. Most open source coders are very happy to have bugs fixed. If however, you are incompetent, and your code looks like something a junior high school student would write, spaghetti code with memory leaks, then you will not be able to get on an open source project that is already highly successful. The better coders will tell you to read the fine manual or other less friendly terms.


As a result of this, the incompetent coder does not get his or her stuff in the project that is already successful. Where they go from there, however is another matter. Many just decide “hey I suck” and go work for Microsoft, play proprietary games, or “volunteer” for proprietary projects, such as being a windows beta tester or volunteering to write a manual for a proprietary game manual and giving the copyrights to the company.


A small minority of the people who end up being told that their code (or artwork or music) sucks, decides that they are right, and everyone else is wrong. They then proceed to ignore or fork the project, and start a totally new and “better” project knowing that eventually, everyone will see how great they are. Most of the time, they suck too much to pull this off. Either they lose interest, or they are just too stupid to learn. The dead project sits around sourceforge taking up space, and no one uses it because it is in pre-alpha, the code doesn't work, and the developer hasn't updated it in years.


Occasionally, however, the monkey pounding at the keyboard produces the open-source equivalent of hamlet. Whether this is from sheer ego and stubbornness, or actually having enough skill to make software that is actually usable I am uncertain. Perhaps due to the stubbornness, they eventually create something worthwhile. The successful projects sooner or later attract other developers, who come to the egotistical keyboard monkey and say “Hey, I can do this better than you.” Now the monkey has a choice, either the monkey can keep an empire of one (or two, or however many idiots the project started out with) or have a better project. The successful projects chose the later route.


The next developers that join the project tend not to be very good, although they have to, by definition, be better than the original monkeys that started the project. They too have big ego and lack skill, but fortunately for us not as much as the original founders. These people, in turn, attract new developers who say “I can do better than these slightly talented monkeys. Now the second layer of monkeys have a decision to make. Either they can let these new, better developers on the project, or they can shoo them away. Now, this is a harder decision, the new monkeys will never let someone who they think is worse then them on the project. The simple reason is this, the original boss monkeys left them in charge of part of the project, it has to get better, not worse, so they only have people working under them who are better than this second later set of monkeys.


This continues down the layers of management depending on how large a project gets, it could stop here, or it could potentially go down hundreds, even thousands of layers. And this explains essentially why it is always mean, egotistical incompetent people who lead these open source projects. It wont' change, because it is hardwired in the fundamental human nature.

Monday, November 13, 2006

C Programmers Reality or Fiction

Today I want to talk about a common urban legend that is widely believed. That is the existence of people who write code in C for fun. I don't believe in it myself since I have never met someone who knows C programing, beyond the hello world and memory leaks anyway. Sure there are a lot of C programs already out there, but simply having a program doesn't mean that a programmer exists or even ever existed. In fact, atheists have used this argument to prove the non-existence of god quite frequently, and since they say they are smart people and always right, I have to agree with them, because I don't want to be stupid.

Besides C programs, I can't really think of any other argument for the existence of C programmers. Most people these days tell newbies to learn a language like python, and not C, because, as newbies soon find out, C produces lots of memory leaks. The thing is, a lot of the good games, such as turn based strategy games such as Battle for Wesnoth (although that is written in C++) and Crossfire are written in C. Supposedly this was done several years ago when there were more C programmers, but I don't know anyone who writes C programs for fun, let alone for work.

Some people claim that C programmers must exist because of the programs, and think they hide in caves or in their basements and write code for fun. I don't believe it. I don't believe in supernatural nonsense like trolls either, because, if I did, I would be stupid, insane, or both. But that doesn't mater the point is a made up story about where C programmers are hiding out does not prove the existence of C programmers. Sure it doesn't refute it either, but that is meaningless without proof, a C programmer.