HandBrake is a GPL-licensed, multiplatform, multithreaded video transcoder.
HandBrake is not a ripper. It converts video, it does not rip it byte by byte. It does not crack the latest DVD copy protection schemes hatched by the studios.
It converts video from nearly any format to a handful of modern ones—that's it.
HandBrake is not everything for everyone for every need. When you desire a ChickenSandwich, search out a local purveyor of prepared foodstuffs. When you desire an über-tool for all your video encoding needs, learn how to use the command line and seek out projects like mencoder.
There's this old geek proverb:
The Law of Software Development and Envelopment at MIT:
Every program in development at MIT expands until it can read mail.
It also goes by the name Zawinski's Law:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Guess what, though? We're trying to avoid that kind of pointless bloat. HandBrake follows the Polyvalent-Program Pattern. This means there is a core library written in C, which is used by several different interfaces on several different platforms. Because of this, it is very unlikely HandBrake will ever include features that are only acheivable in, say, Mac OS X. Nor will HandBrake add features that are only useful for, say, iTunes users. So, for example, there are no plans to automagically add iTunes metadata and artwork to movies ripped with HandBrake. We are following the *nix philosophy of small tools:
It is, however, all too easy to get sloppy about how large your shared context needs to be. The pressure behind Zawinski's Law is the tendency of applications to want to share context for convenience. It's easy to end up carrying around too much weight, too many assumptions, and to write programs that are over-complex, bloated, and huge. The paradigmatic example in the 1990s was the way that the mailto: URL induced the growth of huge mail clients embedded in Web browsers.
The corrective to this tendency comes straight from the old-school Unix hymnbook. It is the Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do—that is, when attempts to partition the problem have been made and failed. This maxim implies an astringent skepticism about large programs, and a strategy for avoiding them: look for the small-program solution first. If a single small program won't do the job, try building a toolkit of cooperating small programs within an existing framework to attack it. Only if both approaches fail are you free (in the Unix tradition) to build a large program (or a new framework) without feeling you have failed the design challenge.
HandBrake and Open Source
an essay by rhester
As the number of new feature requests for HandBrake has risen dramatically in the past few weeks, I consider it prudent to remind end-users of what open source is - and isn't.
Open source is:
- A means to encourage software innovation among diverse groups of programmers
- A policy of open inspection and analysis of source code, both to educate and provide a means for constructive criticism
- A means by which programmers can "scratch their itch" for mental stimulation while at the same time solving computing problems that are frequently applicable even to non-technical users
- Free, both intellectually and in terms of cost
Open source is not:
- A way to get commercial-quality support at no charge
- A free-for-all forum to ask for pie-in-the-sky software features and expect them to be implemented as requested and with no delay
- An invitation to harass and otherwise frustrate a small and dedicated development staff because they didn't do what you wanted
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.
As I stated in another thread (and alluded to again here), 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 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 HandBrake. 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 likely blissfully unaware of our reactions to some of the requests and comments we receive from users.
Just to be clear - I won't lock this topic, because I do want to make sure that users with legitimate, thoughtful questions about the above have the opportunity to ask them in context, but please do not mistake that as an opportunity to debate the merits of open source software or our approach to it. The dissertation above is not negotiable or open for debate - it is what defines HandBrake 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 - we just thought it time to make sure you know as well. :-)