20.04.2012, 19:07:40
I may be blind, but I'm having a hard time finding a source code link anywhere...or a bugtracker, for that matter. No clear description of what's missing for the demo, no half-checked-off roadmap, nothing. Basically, as a programmer, I find no way to assess what state the program is actually in.
The fact that that project apparently has been running for 8 years without a single release isn't instilling confidence, either. Being late on a release is one thing (*cough*), but eight years for even the initial version? I get wanting to do shit properly, but that seems excessive. And as if that weren't crazy enough, they aren't even aiming for a full release after eight years - they're aiming for a demo. I'm kinda scared to see their code base, tbh. Eight years of work for a demo either means one kick-ass demo, or an over-engineered behemoth of bloat.
I have enough I'm procrastinating on that I wouldn't commit to anything anyway, but I would have been willing to check a few bug reports and the source to see if I can write a few quick fixes. Alas, I just plain can't do that. To put it bluntly, this looks like a project by Pokemon enthusiasts for Pokemon enthusiasts, with programming a necessary evil, a roadblock on the way from fun concepting to fun playing. And it shows: The project is geared towards creating the Pokeworld and its inhabitants, with code creation as an afterthought.
Attracting coders for game fan projects is hard. We know that from experience. But attracting them without even as much as a glimpse of what they're getting into? Nigh impossible. You'll get coders who're also Pokemon enthusiasts, because they have a personal interest in advancing the project, but random coders off the Internet? Unlikely.
My advice to that project would be opening the source, putting it in web-readable source control, adding a way to read known issues and submit patches, drafting up a roadmap to the demo, and making all of that easily accessible.
Once programmers can actually see where the code stands, what kind of problems remain and what they'd be dealing with, you have a much higher chance of at least getting random contributions, if not dedicated coders.
tl;dr: If programmers are essential, start gearing the project towards programmers.
Alternative approach: Start learning Ruby as a community. May sound silly, but if all remaining contributors of other fields commit to learning Ruby together, it'll be much less daunting (and more fun) than doing it alone, and you'll get all the programmers you need.
The fact that that project apparently has been running for 8 years without a single release isn't instilling confidence, either. Being late on a release is one thing (*cough*), but eight years for even the initial version? I get wanting to do shit properly, but that seems excessive. And as if that weren't crazy enough, they aren't even aiming for a full release after eight years - they're aiming for a demo. I'm kinda scared to see their code base, tbh. Eight years of work for a demo either means one kick-ass demo, or an over-engineered behemoth of bloat.
I have enough I'm procrastinating on that I wouldn't commit to anything anyway, but I would have been willing to check a few bug reports and the source to see if I can write a few quick fixes. Alas, I just plain can't do that. To put it bluntly, this looks like a project by Pokemon enthusiasts for Pokemon enthusiasts, with programming a necessary evil, a roadblock on the way from fun concepting to fun playing. And it shows: The project is geared towards creating the Pokeworld and its inhabitants, with code creation as an afterthought.
Attracting coders for game fan projects is hard. We know that from experience. But attracting them without even as much as a glimpse of what they're getting into? Nigh impossible. You'll get coders who're also Pokemon enthusiasts, because they have a personal interest in advancing the project, but random coders off the Internet? Unlikely.
My advice to that project would be opening the source, putting it in web-readable source control, adding a way to read known issues and submit patches, drafting up a roadmap to the demo, and making all of that easily accessible.
Once programmers can actually see where the code stands, what kind of problems remain and what they'd be dealing with, you have a much higher chance of at least getting random contributions, if not dedicated coders.
tl;dr: If programmers are essential, start gearing the project towards programmers.
Alternative approach: Start learning Ruby as a community. May sound silly, but if all remaining contributors of other fields commit to learning Ruby together, it'll be much less daunting (and more fun) than doing it alone, and you'll get all the programmers you need.
Forum Rules
(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!
(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.