|What IS "open source" anyway?
The BEST article I've ever read that accurately describes what Open Source really is, appears on and was written by the admin ("rhester") of the handbrake.fr website. I've taken a few (very) small liberties to make it make sense here, out of that context... but it is essentially "as written".
an essay by rhester...
As the number of new feature requests for [our software] has risen dramatically, I consider it prudent to remind end-users of what open source is - and isn't.
Open source is:
Open source is not:
Open source software is exactly what it sounds like: It's software written by a (usually small) group of highly-dedicated people that solved particular problems they themselves had and thought others might find useful as well. Like most things that are free, it comes with no warranty: If it does what you want, that's great - that's exactly why it was offered to you. If not, you have the freedom of choice to either modify it to suit your desires or find another software package that more closely meets your needs.
The features you find in any open source software package are there because at least one programmer needed them and implemented them to meet their own needs (more forward-thinking programmers often at least attempt to make them flexible enough to work for others with similar needs as well).
I am aware of no open source software either currently or previously available that catered to the needs, whims, or desires of end-users. That isn't what it's about. If you want the freedom to tell someone what you want and expect them to do it, that's called "commercial" software, where you make your intentions known with your purchasing decisions and vote with your wallet. That is not "open source".
It is unlikely that you will present a feature request that has not already been considered by the developers, since they are more often than not frequent users of the very tool they are developing.
If a feature is obvious (and available in similar software offerings from others), but hasn't been implemented, it's probably because of a) a lack of time, b) a lack of interest in that particular feature amongst the current pool of developers, or c) a lack of technical knowledge required to implement it.
If the feature isn't obvious, it's probably because it would appeal to an extremely limited subset of users.
From time to time, an esoteric and non-obvious feature (like anamorphic video) will be implemented purely because a core subset of developers are so intellectually interested in it that they provided it out of strong desire and interest coupled with sufficient technical knowledge to make it work.
To put things quite simply, the odds are very much against a feature being implemented purely because someone registered on a support forum and created a post requesting it. That is not compatible with an open source model.
If you have a very strong desire to see a particular feature implemented, your odds of success of ultimately having it become a part of the tool are dramatically increased if instead of asking for it to be implemented, you check out a copy of the latest source code tree, code it yourself (even if slightly incomplete or somewhat buggy), and submit it for peer review by the existing developer pool. Other technical parties are far more likely to help you complete a worthwhile code enhancement that you've clearly put time and thought into than they are to remotely consider doing what you want from scratch just because you want it.
Of course, not all end-users have the technical acumen or programming experience to bring such things to reality. You have three options: a) find a programming friend that you can get excited about your idea and have him follow the above paragraph, b) live without the feature and enjoy the software you have been provided free and proves useful to many others, or c) find a different software package that does do what you want.
I don't mean for the above to sound contrite or condescending - it's merely my attempt to define some boundaries of what is and isn't considered acceptable behavior with respect to any open source project, not just [our project]. I have tried my best to lay it out here in easily-understood terms because I recognize that many of you may not be at all familiar with what goes on "behind the scenes" in an open source project and are blissfully unaware of our reactions to some of the requests and comments we receive from users.
Just to be clear - this dissertation is not negotiable or open for debate - it is what defines [our software effort] and nearly all open source projects, and is provided more as a means of explanation and education than a request for feedback. We already know what we're doing, how we do it and why.