Sorry, that came out wrong What I implied was that most good devs, in general, automatically lean towards writing code with good design patterns, especially for multi-platform projects. I’m not saying we always do that but that’s why we have code guidelines/code reviews to help us when we stray.

Hmmm….maybe I can start making t-shirts with TEAM OSXBMC on them. I’d make out like a bandit.

I see you intentionally misquoted me for effect. No worries, I’ll restate. I said those examples are terrible to compare your fork to. I didn’t mention open source anywhere (and neither did you in the paragraph where you made the statement).

“Someday I’ll go to the Zoolander School for Kids Who Can’t Code Good and then maybe I too will write high quality code.”

Heh.

“Projects like Linux demonstrate how to scale an open source project. There is no formal team, and there is no getting voted off the team.”

Feel free to believe that. The “formal team” for the Linux kernel are the maintainers, and the ultimate authority on what will or will not make it into the Linux vanilla kernel git is Linus Torvals. That’s why there are many unofficial patches for the Linux kernel as well, maybe you weren’t aware of that. Just making statements in an affirmative tone doesn’t magically turn them into facts.

http://en.wikipedia.org/wiki/Linus_Torvalds
http://www.kernel.org/patchtypes/mm.html

Also, projects like Linux and Wine don’t hand out commit access like free candy like we do.

Not to mention that contributors to Linux face constant patch rejection, which of course generally ensures higher quality code. Would you have preferred contributing to XBMC via patches, which may or may not have gotten reviewed immediately, and which you would have had to rewrite many times just to maintain compliance? Maybe, but we thought that giving you commit access would give you much more freedom.

Basically from your post and from your reaffirming multiple times that there will be no team, your stance is that if everyone had unconditional commit access to a source, the project would blossom? Interesting idea and I’d be curious to see how that turns out. I’d reckon QA in such a case would be non-trivial.

Of course on the other hand if you didn’t allow unconditional commit access to everyone, but instead accepted contribution as patches and other forms, you’d be operating exactly like how we do now, so I don’t see how that workflow would be an improvement. The change would be that you would be in complete control, which is basically what this boils down to IMHO and which is a perfectly valid reason to fork. But that’s being straightforward and not good for publicity I suppose. It’s better for publicity to say that Team XBMC restricted your “freedom”. Seems to have worked, as is obvious by reading many of the posts here.

“Thanks again for all your help figuring out OpenGL problems; you are extremely skilled at graphics programming.”

You’re welcome and as I’ve always said, I’m glad to help.

The process goes like this, you submit patches which might or might not be accepted. Sometimes there is discussion, comments and even ridicule if your patch is not up to their quality. If it’s really bad, they will just ignore you. But always someone will review your patch and either accept it or reject it (sometimes by ignoring it). If you are really good with patches and spend about a year or two doing this, then you might, just might get patches accepted without review. But no one but Linus Torvalds has git commit to his tree which is the birthing ground for any Kernel release. So Linux is more a dictatorship than an team environment. You don’t get voted on or off. You just get patches accepted/rejected or ignored. And you don’t get git commit to any git but your own.

With LKML, if you dared push a Linux Kernel GPL binary without source, LKML would eat you alive. They take GPL issues very seriously.

Best of luck with the fork. Don’t forget to fork the documentation and support aspects. That’s expected from open source project forks;)

Projects like Linux demonstrate how to scale an open source project. There is no formal team, and there is no getting voted off the team.

Thanks again for all your help figuring out OpenGL problems; you are extremely skilled at graphics programming.

All the best with the fork guys.

Elan, the goals you mentioned are pretty much part of our goals as well. Hence, our original invitation to you to join the team. Of course our goals apply to all platforms we support, not just OS X.

http://xbmc.org/wiki/index.php?title=The_XBMC_manifesto

As a developer for multiple platforms, I also think that most of those goals can be achieved with superior results using high quality, well thought out, design patterns rather than speedy implementation. For the most part, I think that’s where we differed as developers.

I have to comment on this statement:
“There will be no formal team, nor will there be any getting voted off the team. Think of projects like Mono, Wine, or Linux as models.”

Those are terrible examples.

We gave you commit write access within a week, maybe two, of you just demonstrating your work, without even looking at your code. Good luck trying to get commit access into a another popular GPL project with just a few screenshots. If this were Linux or Wine, you would still be _emailing_ patches to the lead developers, with no certainty that it would even make it into the tree. Even if all your patches were accepted (surely after multiple rewrites), you would still probably not have commit access.

There is always a formal team, whether you like it or not, otherwise it would just be chaos. By “there will be no formal team”, do you mean that nobody else will ever get commit access? If others do, they automatically are part of the team and whether you like it or not, that’s your “formal team”. In addition, by saying “nobody will ever get voted off”, do you mean that once you give commit access to someone, you will never under any circumstance revoke that access? If you do and you consult others to make your decision, that’s the same as getting “voted off”.

You seem to dislike the fact that a vote took place. Would you have preferred it if every developer had the authority to simply kick others off the team and drop their privileges at their whim? IMHO, the decent thing to do, in case of a disagreement within a group, is to obtain the consensus from everyone. Maybe there’s a better way, but a vote seemed obvious and simple enough. No different from the polls you’ve conducted on your blog, except this was internal.

To others reading this blog, the GPL violation was _not_ the only reason why the teams decided to part ways. There were definitely other factors at play.

As someone else mentioned, the official OS X port with continue regardless of the fork and those interested are free to contribute. Yes, we probably follow stricter code guidelines because we’re multi-platform and want all platforms to have the best experience possible. Talented devs should have no problem following them and very talented devs will actually want to follow them. As I mentioned previously, Elan was given commit access fairly soon after he demonstrated that he had a working port, so as opposed to how it seems to be portrayed here, the XBMC team has minimal bureaucracy. We only have guidelines so that team spirit remains high and code quality is top notch. Soon after Elan joined, 3-4 more devs have joined the team.

Anyhow, that’s long enough, good luck to all involved in the fork!

Ultimately though, I think this is probably an unintended blessing. The XBMC codebase, from what little I’ve seen, was not exactly built with multi-platform in mind, both from a philosophical viewpoint, and a historical viewpoint. While the Linux branch guys did great work in alleviating some of this, XBMC is not exactly the most MVC’d codebase. This isn’t as much of a concern when you clone the interface for each platform, but when you’ve got a platform like OS X with unique interface and user experience requirements, you run into problems keeping code parity.

So forking the OS X platform is probably the wisest choice in the long run, until such time as the codebase is completely overhauled to separate the presentation layer from the underlying engine in an easily extensible way. I could be wrong, as I haven’t been closely involved with the project’s code, but this seem likely the ultimate source of frustration and probably elan’s main reason to leave.

Here’s hoping that both branches are successful and thriving for a long time to come.