|
| From: | Lori Nagel |
| Subject: | Re: [libreplanet-discuss] Libre Gaming Manifesto |
| Date: | Fri, 24 Mar 2017 18:35:00 +0000 (UTC) |
Problems in free software game development
This document is the result of a long standing involvement with the free software game development community. Over my eleven years of experience, I have found the following issues with why we don’t have better free software games and overtake Microsoft and all other proprietary operating systems on the desktop with our highly superior games. Perhaps these reasons each by themselves would not doom us, but together they hold us back from destroying proprietary software once and for all. I’m not actually listing every possible problem we could encounter, just some of the main ones I have noticed.
1. Money and business models. Proprietary software has several more mechanism to pay people to develop games than free software. Coming up with and implementing free software business models has been a challenge.
2. Idealogical Issues.
While many people would just be happy to run proprietary games on a free os, many more people would prefer to run free software games on a free software os. The gradient isn’t quite so black and white either, you could run free games with proprietary video card drivers, or work on porting free software games to a non-free os. Maybe the gradient itself isn’t so much the problem as the fact that it is hard enough to find the game you want in any category and it seems like proprietary games on a proprietary os outnumber them all. Another side to this is you can make free code but non-free cultural assets. Without a real strong free culture movement (as strong as the free software movement enforcing ideology,) its hard to say why you need to make the assets free as well other than to include in various free software distros.
3. Technical disagreements. If you thought emacs and vi was a heated agreement or kde vs gnome vs mate vs unity vs xfce vs lxde etc etc, you haven't seen nothing yet. Common arguments that prevent the formation and cohesion of project teams include the following…
1. Programing language
2. Build environment (ie, favorite ide, cmake vs scons vs gnu make)
3. Dependency hunt.
4. Preferred distribution for developing the project on (its hard to get it to work and testing on everything and then they upgrade and change all the libraries so you are back to square one.)
5. version control system.
Etc
4. Project goal disagreements
1. kitchen sink or light weight.
2. Game mechanics
3. graphics direction
4. specific features.
5. requirements for contributions
etc
5. People worrying their workplace might own the software done in off hours and afraid to approach their boss for fear of losing their job.
6. Good dedicated software developers often have obsessive personalities. They might decide to quit software altogether and become a gym rat exercise fanatic for their health.
7. Some people would rather draw or compose music than write software code. This is not a problem per ce but if they don’t sit down and code it, no amount of design documents will bring the software project to life without a programmer.
8. Marketing issues. Its hard to find projects to work on, know about new free software games in your favorite genre too many abandoned projects that had some good code, but no one ever bothered to polish so they would be usable.
| [Prev in Thread] | Current Thread | [Next in Thread] |