It has recently come to my attention that titer has come out of the shadows...sort of.
A brief recap (to the best of my understanding) of events to date [edited as a result of jbrjake's input]:
- Some time ago, titer creates (by himself) an application for BeOS to convert DVD video to other formats, presumably due to the lack of a DVD player for that platform
- Time passes, and titer changes his primary desktop platform from BeOS to MacOS. The application is ported to MacOS (retaining BeOS compilability for some time) and remains focused on DVD backup. Around this time, the original name is abandoned and the application is dubbed HandBrake (a play on words about the original name and purpose).
- Updates continue regularly for some time, the app improves in stability and capabilty and becomes multiplatform, supporting both MacOS (GUI and CLI) and Linux (CLI only). iPod video conversion moves to the forefront and Instant HandBrake is created in an attempt to create a one-shot conversion process for iPod and reduce support headaches
- titer abandons HandBrake. This occurred after a great many structural changes to the code base post-0.7.1/IHB, and it would seem that somewhere around the May 2006 timeframe he simply loses interest in HandBrake and moves on to other open-source projects (including x264).
- Late fall 2006, titer resumes work on HandBrake as a branch of his svn and continues through November 2006.
- Around October 2006, Chris Long and I independently try to pick up the pieces of HandBrake to support the new higher-resolution modes of the iPod Video firmware 1.2+. We hack together something that works, placed on top of revision 69 from m0k's svn, that inherits all of the code and design defects of that revision that did not exist in 0.7.1 (which in turn was not appropriate for this implementation because libmp4v2 was completely inadequate for supporting the new iTunes uuid atom).
- Word gets out we've done this and interest surges. Repeated attempts to reach out to titer for help went ignored, the forums exploded with activity, and we knew it was time to either hang up the spurs or branch and create a support site for what we were trying to accomplish. Obviously, we opted for the latter.
- Our HandBrake branch becomes true open-source, with everyone welcomed and encouraged to contribute code and ideas. Interest develops quickly in the development community and a placeholder development support site is quickly thrown together to give the new work a home.
- Significant progress is made by late December 2006. Not only are the original goals met (and significant defects solved), but bold and new ideas for the future direction of HandBrake are codified and implemented as code branches. Support site's role is expanded to include end-user support, and more formal infrastructure is put into place to bring it all together.
- We get Dugg. We survive, but the realization about the true public popularity of what we're working on does not go unnoticed. Rather than abandon efforts, we reach out to the community for bandwidth relief and receive it in the form of an exceptionally generous offer from ravnwolf, who now hosts our public binaries and contrib libraries.
- A major flaw is discovered regarding interleaved memory management within the integration of HandBrake and libavformat. Significant findings have been made, but no solution exists to date and research continues. Several branches involving far-revamped MacOS GUI support, true support for Windows binaries and advanced multichannel audio are created and flourish.
What I didn't know at the time I began work on HandBrake, and only very recently found out, was that titer had returned to working on HandBrake in mid-to-late 2006 for a short period of time. His focus appears to have been on infrastructure (make vs. jam) and look-and-feel (major changes to the MacOS GUI). No public mention of this activity has been made, and renewed attempts to contact him in December both privately and publicly (posts, e-mail, and PMs) have gone unanswered. It is unknown whether a new public release is forthcoming, but if it is, the guesstimated timeframe is within 1-2 months.
Why is all of this relevant? Well, titer is alive - which was unanticipated and welcomed, but doesn't really bring us forward. He's still going it alone, nobody's really sure where he's headed with things, and from a certain perspective, it appears the advances are moving more backwards than forwards (as the multiplatform aspect of HandBrake appears to now be largely an afterthought).
So what do we do about it? As I see it, we have the following options:
- Take our marbles and go home. We call it a day, say we gave it the good old college try and archive up our svn and save it so it is available to titer should he ever want it or care. This, to me, is by far the least appealing option and one I'm personally not seriously considering.
- Reach out to titer - again - and see if we can get our changes integrated into his svn and bring things back together again. This is problematic, for two reasons: a) even if they were, some of the directions we're headed, like Windows support and multichannel audio, aren't even being considered by titer at this time and may prove difficult to integrate properly, particularly if he isn't interested in them, b) odds are that, even if a) were accomplished, the svn will remain closed and the app firmly titer's - which is his right, of course, but the reason for the success of so many popular open-source apps is specifically because they are open for contribution - something titer doesn't support, doesn't seem likely to in the future, and doesn't appear that he'd be able to support long-term (take it from me, supporting genuinely open and useful infrastructure is not easy and is rather time-consuming). As a result, while in a perfect world, this is the option I'd most prefer, the reality is that it isn't likely to work, either in the short term or long term.
- We recognize that we have a great deal of genuine value to contribute to the application and its dedicated user base and we resolve to continue what we've begun - as a completely separate, branched application that is certainly going to go in radically different directions than titer originally conceived or will go in the future. This is a good thing in my opinion, a true demonstration of the spirit of the OSS model, and what allows for real progress for any application. Many precedents for this exist - xvid and Ubuntu are but two particularly notable examples.
If we're going to do this, what would it take? In reality, not much. We come up with a name for our app (to avoid massive user confusion and avoid seriously - and unnecessarily - [Censored] off titer), spin a new domain, get everything moved over and redirected, get a new icon and a bit of artwork, and decide on a versioning scheme and roadmap (which isn't likely to differ much from what we already laid out). As time passes, developments in titer's HandBrake (the make vs. jam build process is notable...but I like our GUI better) could be leveraged/integrated as appropriate, as a take-what-you-like-and-leave-the-rest approach. Again, it's the basic definition of the OSS model - and, of course, titer would be free to do the same with us (and can you imagine one of our advancements being incorporated nearly as-written in his HandBrake? How cool would that be?).
But is it worth it? If people are going to remain dedicated to and interested in our work as developers, yes - otherwise we will stagnate and die. Clearly, the interest (and hard work!) is there, but if not sustainable, the effort will fail. I personally see no reason why this would happen, but if anyone has lost drive as a result of realizing we are now indirectly and unintentionally 'competing with' titer, we're going to be in trouble.
We have the support and interest of the end-user community - if you have any reason to doubt this, you need but take a look at our weblogs. People peer at what we're doing with natural reservations, since we've yet to produce a public release (and this is completely normal - and will only get worse right after we spin, if we do, until we release), but they are thankful that we have taken an approach of being so public and above-board with our work and that we have openly engaged and recruited the OSS development community and welcomed their contributions.
There is no legal problem - titer's code is GPL'ed OSS and thus absolutely allows for such action. There is no ethical or moral dilemma that I can see - titer had to know the possibility that a fork would occur when he GPL'ed his code but made his svn closed for updates to anyone but himself. We're not "stealing" his work, but expanding on it and taking it in new and wonderful directions in the truest definition of open source.
Are you guys with me? I'm more than willing to put in the time to try to make this a success, but we need to reach a decision fairly quickly before we invest significant additional resources towards an aim we may not meet.
If you managed to read this far, I apologize for the extraordinary length of this post, but I would sincerely appreciate your thoughts and comments. I may have ended up the 'de-facto' project leader for our efforts by default, which I think is fine, but this is not my project - we are a community, and we will thrive or perish as one.
Onward and upward, or down and out?
Rodney
titer lives...do we?
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
titer lives...do we?
Last edited by rhester on Sun Jan 14, 2007 9:33 pm, edited 3 times in total.
We've discussed this scenario on the IRC channel.
If titer makes a new release, I think, perhaps, the best way to look at our fork is as a sandbox. We can use it to test out new features, and encourage titer to take what he likes and leave what he doesn't. This lets HandBrake benefit from a collaborative development model without forcing titer to deal with a bunch of people screwing with his code base. At the same time, we take what fixes we need from his source--for example, I was only able to clean up the rate control methods in encx264.c by seeing how he'd dealt with the new libx264 in his makefile branch.
Personally, I'll remain involved. I see little possibility that titer would want to add the sorts of things I'm interested in, so the only chance I have of seeing those features effected is to do them myself. That can't happen with titer's locked down svn, so I'm not going anywhere.
Changing the name, though, will be necessary. It is unfair to titer to make him deal with support issues from our code, and that will inevitably happen if we keep the name.
I've proposed on IRC that, in the case titer pushes out a new HandBrake release, we rename ours to FootPedal.
A few timeline notes:
- HandBrake was a Mac OS program long before the whole iPod video thing happened, focused on backing up DVDs for personal use.
- Titer "abandoned" the program around May. By fall, his interest was renewed. The branch happened only shortly after the fork.
- Titer didn't return to the program in December. His last check-in was the end of November. There haven't been any commits since.
If titer makes a new release, I think, perhaps, the best way to look at our fork is as a sandbox. We can use it to test out new features, and encourage titer to take what he likes and leave what he doesn't. This lets HandBrake benefit from a collaborative development model without forcing titer to deal with a bunch of people screwing with his code base. At the same time, we take what fixes we need from his source--for example, I was only able to clean up the rate control methods in encx264.c by seeing how he'd dealt with the new libx264 in his makefile branch.
Personally, I'll remain involved. I see little possibility that titer would want to add the sorts of things I'm interested in, so the only chance I have of seeing those features effected is to do them myself. That can't happen with titer's locked down svn, so I'm not going anywhere.
Changing the name, though, will be necessary. It is unfair to titer to make him deal with support issues from our code, and that will inevitably happen if we keep the name.
I've proposed on IRC that, in the case titer pushes out a new HandBrake release, we rename ours to FootPedal.
A few timeline notes:
- HandBrake was a Mac OS program long before the whole iPod video thing happened, focused on backing up DVDs for personal use.
- Titer "abandoned" the program around May. By fall, his interest was renewed. The branch happened only shortly after the fork.
- Titer didn't return to the program in December. His last check-in was the end of November. There haven't been any commits since.
If hes not looking at windows and linux compatibility then is say we stick with this. It is great we have a multi platform here and we've made good advances.
If we don't get a deal stuck with Titer then i say we continue, maybe under a different name if he starts going public again and we can always incorporate any changes he makes that would benefit this application.
Once we get this memory/ performance issue fixed we'll have a new build that has alot of improvements and newer codecs availble for the public. We have new GUI's that are strides ahead of whats currently available. I'm not about to let you walk away from the excellent work thats been done
If we don't get a deal stuck with Titer then i say we continue, maybe under a different name if he starts going public again and we can always incorporate any changes he makes that would benefit this application.
Once we get this memory/ performance issue fixed we'll have a new build that has alot of improvements and newer codecs availble for the public. We have new GUI's that are strides ahead of whats currently available. I'm not about to let you walk away from the excellent work thats been done
Precisely what I had in mind.jbrjake wrote:We've discussed this scenario on the IRC channel.
If titer makes a new release, I think, perhaps, the best way to look at our fork is as a sandbox. We can use it to test out new features, and encourage titer to take what he likes and leave what he doesn't. This lets HandBrake benefit from a collaborative development model without forcing titer to deal with a bunch of people screwing with his code base. At the same time, we take what fixes we need from his source--for example, I was only able to clean up the rate control methods in encx264.c by seeing how he'd dealt with the new libx264 in his makefile branch.
Agreed.jbrjake wrote:Personally, I'll remain involved. I see little possibility that titer would want to add the sorts of things I'm interested in, so the only chance I have of seeing those features effected is to do them myself. That can't happen with titer's locked down svn, so I'm not going anywhere.
Yep. In addition to the things I mentioned in my treatise, we're also looking at having to change the svn repository name (dead-simple, but everybody has to have their stuff checked in with nothing checked out/active) and the filenames within the code (hblib->??lib, HBTest->??CLI?, etc.). Nothing too difficult, just tedious.jbrjake wrote:Changing the name, though, will be necessary. It is unfair to titer to make him deal with support issues from our code, and that will inevitably happen if we keep the name.
I've proposed on IRC that, in the case titer pushes out a new HandBrake release, we rename ours to FootPedal.
FootPedal, huh? Not bad. I was angling towards SpeedBrake (in homage to aircraft and the recent performance gains). We'll do a poll once we get more feedback on whether we continue...but so far, it looks like we're on.
I was deadly serious about needing new artwork. Right now I'm "borrowing" titer's favicon.ico and some of his GIF/PNG imagery and I don't feel a bit good about it...I did so only because it was instantly recognizable as HandBrake (as is the application icon). If we change names - and I agree we have to - it all has to be redone. I won't "rip off" anyone's IP like that.
Thanks for the corrections. I'll go back and update the mainline post for accuracy. I came into HandBrake rather late in the game and wasn't around for much of this. That makes me no less a fan, however.jbrjake wrote:A few timeline notes:
- HandBrake was a Mac OS program long before the whole iPod video thing happened, focused on backing up DVDs for personal use.
- Titer "abandoned" the program around May. By fall, his interest was renewed. The branch happened only shortly after the fork.
- Titer didn't return to the program in December. His last check-in was the end of November. There haven't been any commits since.
Rodney
I'm not worried about having users :) I'll help out simply to get what I want out of it. If something titer does is something I want, then I'll use it! Freedom of choice, nothing wrong with giving users (or ourselves) one.
I'll stick around simply for the learning experience. I'll have you guys applying small amounts of pressure to all sorts of things which can do nothing but motivate me to try!
Cheers mates!
I'll stick around simply for the learning experience. I'll have you guys applying small amounts of pressure to all sorts of things which can do nothing but motivate me to try!
Cheers mates!
One important point I didn't make earlier that I meant to - I don't think we can/should wait until titer pushes a new public release to rename our fork. If we already have 2-3 public releases behind us, and then he releases essentially a completely different application with the same name, can you imagine the sort of mass confusion it will cause to both communities? If we're going to rename, and I can't see how we can't, we need to do so before our first public release.jbrjake wrote:I've proposed on IRC that, in the case titer pushes out a new HandBrake release, we rename ours to FootPedal.
Rodney
Absolutely true. I was always uncomfortable with releasing a "Handbrake" 0.7.2. Imagine, (and we know from the digg incident how quickly people will download it) we get a large user base under the name Handbrake, then in a couple of months, titer releases his new Handbrake. Can you imagine the confusion?
I personally think this is for the best. Whether or not titer is actively developing on Handbrake right now is really irrelevant, we would be betting on whether or not he eventually will. I think it is reasonable to conclude that none of us really has any idea what he might do with Handbrake. Therefore, it probably makes sense to leave Handbrake with titer, and unveil the new "FootPedal" or "SpeedBrake" .... or "ChickenSandwich" ... or whatever.
As far as that goes, I also do NOT think we should release ChickenSandwich, using titers mac gui. Windows is probably not a big deal as he never wrote that anyways (thanks sr55, shes all yours!).
I personally think this is for the best. Whether or not titer is actively developing on Handbrake right now is really irrelevant, we would be betting on whether or not he eventually will. I think it is reasonable to conclude that none of us really has any idea what he might do with Handbrake. Therefore, it probably makes sense to leave Handbrake with titer, and unveil the new "FootPedal" or "SpeedBrake" .... or "ChickenSandwich" ... or whatever.
As far as that goes, I also do NOT think we should release ChickenSandwich, using titers mac gui. Windows is probably not a big deal as he never wrote that anyways (thanks sr55, shes all yours!).
Given we want to release ChickenSandwich as soon as possible, under whatever name, if we don't use the 0.7.1 GUI, what GUI can we spin that quickly and have effectively tested? GenII?dynaflash wrote:As far as that goes, I also do NOT think we should release ChickenSandwich, using titers mac gui. Windows is probably not a big deal as he never wrote that anyways (thanks sr55, shes all yours!).
Rodney
Well, benlake is working on one but I think he just has it in mockup phase, right now.rhester wrote:Given we want to release ChickenSandwich as soon as possible, under whatever name, if we don't use the 0.7.1 GUI, what GUI can we spin that quickly and have effectively tested? GenII?dynaflash wrote:As far as that goes, I also do NOT think we should release ChickenSandwich, using titers mac gui. Windows is probably not a big deal as he never wrote that anyways (thanks sr55, shes all yours!).
Rodney
Gen II is available and works fine (no "wiring" changes really just a reorg of the fields and features from 0.7.1).
Or, if we dont want that one. Out of the shoot, in the interest of speed, at least re-organize the 0.7.1 gui so at least it is not a complete clone. What I am saying is, the widgets and wiring doesnt need to change, but a bit of graphic work (could go to a textured window, like MTR and DTOX) and window reorganization would set it apart from HB.
Basically just set the gui apart from titers, at least somewhat. Behind the scenes we have been having some future gui conversation on our irc channel. Some nice stuff by benlake and ideas by others. But, that may take some time to develop.
The question is time to our release for the rest of the project. Maybe we need a new Roadmap to ChickenSandwich (nice codename, huh), basically a punchlist of fixes. If we are a ways out on the mem leak, then gui has more time to develop and test. If we are almost there, then we will go the short re-org route.
I am just concerned that we rebrand our product from HB, then go and use the exact same gui. Thats all. Maybe it is not a concern. Just thought I would bring it up as we talk logos, icons, name, etc.
I imagine we will need to rename the cli as well.
Food for thought.
On the GUI choice for the first release, I'm with dynaflash; How much time do you all think we have in getting the encoding stable? It doesn't seem to be just a memory leak now that various libraries have been upgraded.
I think dynaflash and I could get the GUI up to speed in a few weeks, but will the app be ready?
I think dynaflash and I could get the GUI up to speed in a few weeks, but will the app be ready?
I consider it extremely unlikely it was ever a memory leak in libavformat or ffmpeg. I use both routinely in custom builds of mencoder, for both avi and mp4 containers, and have never seen such a thing. It has to be something with the way HandBrake is presenting the content for muxing.benlake wrote:On the GUI choice for the first release, I'm with dynaflash; How much time do you all think we have in getting the encoding stable? It doesn't seem to be just a memory leak now that various libraries have been upgraded.
Rodney
A few thoughts:
It's always possible that titer wanted to make a few changes to HandBrake for his own personal use, and did so on the svn he already had set up (for speed and convenience). It might be that that's all we're seeing. I don't think it changes these discussions, however. This project should be seen as distinct, to avoid confusion.
I'd definitely suggest a new name, but tbh I'd keep the GUI the same for now. For the short-term maintenance release, the less that changes the better. Get something out there based on Handbrake 0.7.1, with the same GUI but a different name and icon, and then think about the "new" version. Otherwise there's no way we'll have something ready and tested for just after the release of AppleTV.
Just my 2p! BTW, I'm in for helping out with the audio side of things. Can't commit too much time, but I'll try and get 5.1 included and then chip in as needed.
It's always possible that titer wanted to make a few changes to HandBrake for his own personal use, and did so on the svn he already had set up (for speed and convenience). It might be that that's all we're seeing. I don't think it changes these discussions, however. This project should be seen as distinct, to avoid confusion.
I'd definitely suggest a new name, but tbh I'd keep the GUI the same for now. For the short-term maintenance release, the less that changes the better. Get something out there based on Handbrake 0.7.1, with the same GUI but a different name and icon, and then think about the "new" version. Otherwise there's no way we'll have something ready and tested for just after the release of AppleTV.
Just my 2p! BTW, I'm in for helping out with the audio side of things. Can't commit too much time, but I'll try and get 5.1 included and then chip in as needed.
Name Change
Hi all.
I'm not a coder, just a user, but I thought I'd give you my thoughts on a new name.
As this is going to become a new application, I think it might be good to create a name that hints at what the application does.
If you're a new user, Handbrake doesn't give you any clue as to what you're getting.
If you were to call the app 'DVDConverter' for instance, it would be clear that it has something to do with converting DVDs and may well help users finding it more easily on the web.
BTW, I'm not suggesting this should be the new name, it's just there as an illustration.
I'm not a coder, just a user, but I thought I'd give you my thoughts on a new name.
As this is going to become a new application, I think it might be good to create a name that hints at what the application does.
If you're a new user, Handbrake doesn't give you any clue as to what you're getting.
If you were to call the app 'DVDConverter' for instance, it would be clear that it has something to do with converting DVDs and may well help users finding it more easily on the web.
BTW, I'm not suggesting this should be the new name, it's just there as an illustration.
Re: Name Change
The problem with a "descriptive" name is that the function of the app might evolve over time. Suppose the DVD were to be supplanted, if not by Blu-Ray or HD-DVD, then perhaps by some other media, and this app was still being used to convert them.S Paris wrote:Hi all.
I'm not a coder, just a user, but I thought I'd give you my thoughts on a new name.
As this is going to become a new application, I think it might be good to create a name that hints at what the application does.
If you're a new user, Handbrake doesn't give you any clue as to what you're getting.
If you were to call the app 'DVDConverter' for instance, it would be clear that it has something to do with converting DVDs and may well help users finding it more easily on the web.
BTW, I'm not suggesting this should be the new name, it's just there as an illustration.
A lot of people are now using this app to put files on their portable players, especially the iPod & PSP, but soon people might be using it to make their files AppleTV-ready, and in a few months, it might be some other gadget.
I suggest the name <b>"MediaFork"</b>
It has the nice little double-meaning referring to its origin of forking off from HB, and also refers to the fact that it is a "utensil" of sorts for manipulating media files.
Plus, it has that festive mixed-case naming convention, which fills me with a warm nostalgia for the dot-com bubble days... But if you feel differently you could always lower-case the F or else add a space in the middle. Whatever.
Oh, and since the icon for Mac the Ripper is a knife being stabbed into a DVD, the perfect icon for this app would become a rather obvious choice. ^_^
Cool. How about the icon for MediaFork be a fork stuck in a ChickenSandwich !
If we are serious about forking (which it sounds like some folks are) we probably will want to come up with some kind of a name soon, so we can start the internal changes required. For instance, renaming HBTest, .plist info (mac) whatever is required on the win side, libhb, obviously the website stuff, etc. I know all of this has been mentioned before, but once we pull the trigger with a name, alot of this will take some time to implement, I would imagine.
How do you guys propose we decide on a name, run a poll? Wait until we all agree ( lol. devs agree, riiiiiggghhtt
) Personally, I like most of them and figure that whatever we name it, if the software is good, people will like it.
If we are serious about forking (which it sounds like some folks are) we probably will want to come up with some kind of a name soon, so we can start the internal changes required. For instance, renaming HBTest, .plist info (mac) whatever is required on the win side, libhb, obviously the website stuff, etc. I know all of this has been mentioned before, but once we pull the trigger with a name, alot of this will take some time to implement, I would imagine.
How do you guys propose we decide on a name, run a poll? Wait until we all agree ( lol. devs agree, riiiiiggghhtt
) Personally, I like most of them and figure that whatever we name it, if the software is good, people will like it.Seriously, that is exactly what I was thinking. I like it because it has no reference to any part of the "HandBrake" name.rhester wrote:I am torn between running a poll and just going with MediaFork.
Very true. With the many developers sending our program in different directions, and new target platforms (ie.appleTv, etc.) coming quickly, I can see new uses becoming more and more common.golias wrote:The problem with a "descriptive" name is that the function of the app might evolve over time. Suppose the DVD were to be supplanted, if not by Blu-Ray or HD-DVD, then perhaps by some other media, and this app was still being used to convert them.
A lot of people are now using this app to put files on their portable players, especially the iPod & PSP, but soon people might be using it to make their files AppleTV-ready, and in a few months, it might be some other gadget.
I suggest the name <b>"MediaFork"</b>
One note, the abbreviation we now refer to as HB (or internally "libhb") would now become "MF"!!! As in "libmf"! Actually, it has a nice ring to it!