Will be our product management our fatal flaw?
As a Pidgin user, I followed up to a certain point a ticket that became so famous it has been slashdotted and have had to become a static page after that. To put the long story short Pidgin devs decided to take a feature away, a certain amount of its community felt it was wrong and a fork were born. The result of the aggro convo that took place there is funpidgin, a fork whose purpose in life is do what the mother project were unable to achieve: keep its users content.
I were to stick with my old 2.3 version of the Pidgin client but rather decided to give the fork a try, and so far results have been acceptable. And I like the resizable input widget instead of the automagic thingy Pidgin devs liked so much.
Many articles and debate were written around this situation, yet there is one I found inspiring and I wanted to share for your consideration here. It’s a remarkable comment Paul Young made at his Product Beautiful blog. It puts into the table aspects that many FOSS products (yeah, L2J included) should consider from the Product Management perspective (yeah, that one we barely think of). A week later or so, he takes the topic back to further ellaborate on his vision of what Product Management shall imply in our living as Open Source product developers. I can’t stop insisting you take a look at both.
Thanks for the mention. I’d offer to throw in some Product Management but game servers aren’t my area of expertise!
I’m curious though, which side of the fence your team considers itself to fall on. I define it as “we develop for our users” vs. “we develop for ourselves.” Do you see it as a black/white issue, and where do you fall?
Being an open-source emulator of another game, we have a clear-cut guideline of the features we will implement. We do implement custom features and mods, but we always consider those as the lowest priority.
I’d say, for the most part we follow the “it’s a hobby so it’ll be done when it’s done” policy. In that sense you can say we develop for ourselves. Nevertheless, the weight of a ticket/bug-report and how fast someone decides to start working on it as opposed to working on another ticket typically depends on a) How strongly it affects the game mechanics and game balance, b) how much demand there is for repair that particular issue, c) how much information we have for the way it *should* work (based on the game we attempt to emulate).