[READ] There's no such thing as 'Free Developers'
[READ] There's no such thing as 'Free Developers'
There are quite a few 'free developer wanted' posts on this forum. I don't think it's a good idea. Read here why and please let me know what you think.
http://blog.forsakenlabs.com/2009/08/05 ... developer/
http://blog.forsakenlabs.com/2009/08/05 ... developer/
Yeah this is true. I recommend any mmo designers to read "Why you don’t want free developers".
Sadly sometimes even if you're paying them they can still cause all of the listed problems (Lack of commitment, bad code, loss of interest for maybe a better paying proposition), so you have to look carefully either way.
Sadly sometimes even if you're paying them they can still cause all of the listed problems (Lack of commitment, bad code, loss of interest for maybe a better paying proposition), so you have to look carefully either way.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
I am glad that I am doing this just as a hobby, so I can do it alone and don't have to rely on anybody. And I am well aware that I will most likely not make the next WoW , but something to have fun playing could come around anyways.
Dustbin::Games on the web: https://www.dustbin-online.de/
Dustbin::Games on facebook: https://www.facebook.com/dustbingames/
Dustbin::Games on twitter: https://twitter.com/dustbingames
Dustbin::Games on facebook: https://www.facebook.com/dustbingames/
Dustbin::Games on twitter: https://twitter.com/dustbingames
Op post++;
While, like the blog said, there are some exceptions (I've known a few, enough to know they genuinaly exist), they are completelly lost in the sea of ppl that will fail to meet proper requirements for work (on either side of the table). So, at the very least, if you're gonna be or hire free dev, at least do it with someone you know very well, very very well.
While, like the blog said, there are some exceptions (I've known a few, enough to know they genuinaly exist), they are completelly lost in the sea of ppl that will fail to meet proper requirements for work (on either side of the table). So, at the very least, if you're gonna be or hire free dev, at least do it with someone you know very well, very very well.
Well this point of view seems to me a bit flat. Sounds like "never try to do a really big thing because you wont finish it". Okay you are right. With enough money in your wallet everything is bit more easier but who of you has the money to pay a complete team? I have not! But i wont stop trying to develop a bigger project because of the fact i have not my own gamestudio.
Its a hobby for me. I spend time if i have time and if i want to spend it. The other members of the team do the same. Many came and went away. Thats okay. We have learned many things. The have redesigned many parts. We are evolveing, getting better, collecting members who really want to finish this project. And maybe one day we can show something up. If not its would be okay too because everybody gained something. By the way, working together make much more fun for me then bubbling along alone. But this is only my point of view. Just a point of view like yours. Not more not less.
Its a hobby for me. I spend time if i have time and if i want to spend it. The other members of the team do the same. Many came and went away. Thats okay. We have learned many things. The have redesigned many parts. We are evolveing, getting better, collecting members who really want to finish this project. And maybe one day we can show something up. If not its would be okay too because everybody gained something. By the way, working together make much more fun for me then bubbling along alone. But this is only my point of view. Just a point of view like yours. Not more not less.
@Dorth: I agree. It's okay to hire a 'free developer', but then it should be someone you really know. And that means it's useless to drop a job opening post on this forum for example.
@Nox: I'm not saying you shouldn't try to do something big. As a matter of fact I'm working with a friend on a game as well. We're not yet incorporated and we both work in our free time. But with someone you have a history with, it's okay to make the commitment.
Having project members come and go is generally not a good idea. When a member leaves, a part of the knowledge you build up leaves. Also, the code is very likely to turn into a mess, because every developer has his own coding style. In the end, this mess will become unmaintainable.
Again, I'm not saying you shouldn't do hobby projects and get others to help you. But if you are serious about releasing and supporting the game, you need to set up a company for it and make sure you can guarantee the future and quality of your game.
Hey, Steve Jobs started making computers in his garage too.
@Nox: I'm not saying you shouldn't try to do something big. As a matter of fact I'm working with a friend on a game as well. We're not yet incorporated and we both work in our free time. But with someone you have a history with, it's okay to make the commitment.
Having project members come and go is generally not a good idea. When a member leaves, a part of the knowledge you build up leaves. Also, the code is very likely to turn into a mess, because every developer has his own coding style. In the end, this mess will become unmaintainable.
Again, I'm not saying you shouldn't do hobby projects and get others to help you. But if you are serious about releasing and supporting the game, you need to set up a company for it and make sure you can guarantee the future and quality of your game.
Hey, Steve Jobs started making computers in his garage too.
in my opinion whats not correct. If somebody comes and leave i dont loose the knowledge i gained from it. The thing with the code depends on the state. If it is finished, stable and fits the coding style rules of the project maintaining the code isnt s hard. But in the other cases dropping the code is mostlikely necessary. But anyway. The learned thing dont get lostariejan wrote:[...]When a member leaves, a part of the knowledge you build up leaves. Also, the code is very likely to turn into a mess, because every developer has his own coding style.[...]
Let me tell you true story. In Eindhoven there was a computer science guy working for Philips. He was obsessed with algorithms in general and compression algorithms in particular. On a good day, this man creates in his spare time a compression algorithm so good that it can compress any file to 10% it's size. Leaving other algorithms like those used by ZIP and RAR far behind.Nox wrote:in my opinion whats not correct. If somebody comes and leave i dont loose the knowledge i gained from it. The thing with the code depends on the state. If it is finished, stable and fits the coding style rules of the project maintaining the code isnt s hard. But in the other cases dropping the code is mostlikely necessary. But anyway. The learned thing dont get lostariejan wrote:[...]When a member leaves, a part of the knowledge you build up leaves. Also, the code is very likely to turn into a mess, because every developer has his own coding style.[...]
The guy is afraid that his idea will be stolen by a big corporation, so he keeps it all in his head and starts talking to his employer about licensing the compression algorithm. This would make him a huge load of money.
Then, as this guy is leaving his house for Philips to give them the algorithm and sign the contract that is going to make him a millionaire, he drops dead in his front yard.
No one ever found any evidence of the algorithm and no one has ever come close the compression rates he achieved. Now, some will say he never had the algorithm, but that's not the point of this story.
You're the guy having a complete overview of your project. If you drop out for some reason, the project is lost. The same is true for developers that have a lot of knowledge about a specific part of the code base, and then leave. You lose their knowledge and it'll take you time and effort to continue development.
Having developers walk in and out is not a good idea. Especially if your betting your own or someone else's money on it (through investments).
Well. As you already mentioned im the master of code . If I go the project will be dead. Thats correct. But the things about teamwork, maintainable design, different solution worked out by me or the teammembers are not lost. I dont know how you and your friends are working but we use a svn and cross-read the source of the others. Sometimes we improve it or learn something. Thats not lost in any case (okay maybe some nukes kick of all of our pcs and the svnserver ).
You are right: with money, a company, equipment and a professional team things look different, more predictable. But god damnit, we are hobbyists. In most of the cases we can be proud if we can show something up and if only a few guys take note of our work. For me its fun and learning.
And for you?
You are right: with money, a company, equipment and a professional team things look different, more predictable. But god damnit, we are hobbyists. In most of the cases we can be proud if we can show something up and if only a few guys take note of our work. For me its fun and learning.
And for you?
I like the article ariejan, it has some truth in it. Does that story, or was it just a motivational? (I'd actually like to know, because that's crazy.)
At any rate, one thing that can help reduce the chance of the code becoming a mess is creating a standard. If a programmer doesn't want to follow it, then they aren't meant for your project. If they find something that's not in it, make sure to tell them to add it. Programmers should have no problem changing their style, and if they'd rather not conform, then they may be a little too stubborn to even contribute to your project. (On the other hand, take criticism into consideration...maybe your coding specification isn't exactly the best or the most productive.) Also, try to keep the specification small or no one will read it.
At any rate, one thing that can help reduce the chance of the code becoming a mess is creating a standard. If a programmer doesn't want to follow it, then they aren't meant for your project. If they find something that's not in it, make sure to tell them to add it. Programmers should have no problem changing their style, and if they'd rather not conform, then they may be a little too stubborn to even contribute to your project. (On the other hand, take criticism into consideration...maybe your coding specification isn't exactly the best or the most productive.) Also, try to keep the specification small or no one will read it.
TheQuestion = 2B || !2B
-
- Posts: 222
- Joined: Mon Jan 19, 2009 10:03 pm
- Location: Miami, Florida
- Contact:
Thats not really true, developers working for free are doing for one of 2 reasons:
1. They need experience
regardless of how good you are, you wont get hired by a professional company if you dont have experience. example: "I've been programming for 15 years" really! how many projects have you worked on? "Only 2, but thats because I'm too good and people are scared to hire me since they think I'll call them stupid".
2. They're bored kids
Most people who work for free are teenagers who are bored and looking for something to do (like me ). Even though alot of them use age as an excuse("oops my bad, I'm only 14"), it doesnt mean they're unreliable. we dont have to worry about mortgage or bills either because we live with our parents and they do that, so we can spend more time working on a project.
1. They need experience
regardless of how good you are, you wont get hired by a professional company if you dont have experience. example: "I've been programming for 15 years" really! how many projects have you worked on? "Only 2, but thats because I'm too good and people are scared to hire me since they think I'll call them stupid".
2. They're bored kids
Most people who work for free are teenagers who are bored and looking for something to do (like me ). Even though alot of them use age as an excuse("oops my bad, I'm only 14"), it doesnt mean they're unreliable. we dont have to worry about mortgage or bills either because we live with our parents and they do that, so we can spend more time working on a project.
Dorth is right.
If the person in example #1 can't find the self-motivation to work on their own projects to gain experience, then sadly they shouldn't be on the team. They'll slow it down in their attempts to learn. Let them work independently, then find team-based work.
Example #2 has two problems on different spectrums. On the first one, never hire someone who is just sitting there bored. This goes back to the self-motivation aspect. And secondly, age shouldn't even be a question; you should be able to hire someone off of past projects/experiences.
Those are my opinions.
If the person in example #1 can't find the self-motivation to work on their own projects to gain experience, then sadly they shouldn't be on the team. They'll slow it down in their attempts to learn. Let them work independently, then find team-based work.
Example #2 has two problems on different spectrums. On the first one, never hire someone who is just sitting there bored. This goes back to the self-motivation aspect. And secondly, age shouldn't even be a question; you should be able to hire someone off of past projects/experiences.
Those are my opinions.
TheQuestion = 2B || !2B