What is Google's plan with the Open Source community?

[stuckless]

This is really directed at you, Jeff, and hopefully you can answer some of these questions.

So now that code is open source, does Google plan on releasing a "product" from that source code, other than what is being used in Google Fiber TV. ie, Should we ever expect that Google (ie, you) will create and host a binary downloadable product that we all know as SageTV?

If Google is not intent on releasing a product, what would be point of sending you pull requests? ie, my only reason to do so, so that if a product is created, then it contains the changes I want

If Google is not intent on releasing a product, would it not be more beneficial to have a separate group of people maintain an "unofficial" repo for SageTV changes, and then Google would simply pull what they want, if anything, from that repo. This "unofficial" repo would host the product downloads for SageTV. Can we even use the SageTV name in that case?

[Fuzzy]

I know you directed it at Jeff, and obviously, I have no idea what google's intent is, but I will say that if anything, google fiber seems like more of a fork off of sagetv than does v9. v9 has, for the most part, identical functionality to v7 last we saw it. v8, on the other hand, seems to be quite different. There are some key architectural changes in there that we don't have in v9. I don't see them pulling much from our work to use in Google Fiber unless we somehow create some pretty amazing stuff.

For now, I like that Jeff is acting as arbiter on the master branch, and I think that should probably remain for a while at least. This is a 12 year old project, with a lot of code quirks buried in there, no doubt. It'd be good to keep that guy heavily invested for a while. :-)

[Narflex]

There's no intention from Google to turn SageTV back into a product like it used to be. The only restriction with this Google owned repo we're working from is that I'm not allowed to make anyone else who doesn't work for Google an admin....but I'm not familiar enough with GitHub to know what kind of restriction that really means.

The SageTV name is attached to this code...so I don't see any issue with using that name in forks...but I'm not a lawyer.

It's probably not a bad idea at all to have another repo which hosts the 'built' versions of everything. Something like "SageTVBinaries"...or whatever you kids are calling them these days.

As for V8 vs. V9...I put everything from V8 into V9 that I thought would be of interest. The only major architectural difference is that we created a 'UI code generator' that would take the STV code and generate actual Java code which would be compiled and executed in order to dramatically improve performance (but that only really matters on embedded devices...not on PC servers). That change also made the overall UI code MUCH uglier from the refactoring required to make that happen...so I did not include that change because I thought it would be much more useful the way it was (although there were plenty of UI bug fixes I did port over). Also, all the stuff specific to Google fiber was not included (such as all the backend system communication, VOD support, logging for stats collection, etc.) as those would have provided zero use.

So I'm not really sure what you're referring to with V8 vs. V9 key architectural differences.

[Fuzzy]

I was working off the assumption that there were also content protection measures in place in the v8 implementation that obviously wouldn't have made their way to v9.

[Narflex]

Originally Posted by Fuzzy

I was working off the assumption that there were also content protection measures in place in the v8 implementation that obviously wouldn't have made their way to v9.

That'd be some pretty bad content protection if it lived inside of Java code..wouldn't it be? The only content protection stuff that was ever done in the Java layer was at the management level (i.e. update this, update that, etc.)...it never, ever would touch actual keys/licenses/etc.

[Fuzzy]

I didn't say it was in the java code - just that it'd be a part of the v8 version of sage.. :-) there's an awful lot of non-java on the git repository right now.

[stuckless]

Originally Posted by Narflex

There's no intention from Google to turn SageTV back into a product like it used to be. The only restriction with this Google owned repo we're working from is that I'm not allowed to make anyone else who doesn't work for Google an admin....but I'm not familiar enough with GitHub to know what kind of restriction that really means.

The SageTV name is attached to this code...so I don't see any issue with using that name in forks...but I'm not a lawyer.

It's probably not a bad idea at all to have another repo which hosts the 'built' versions of everything. Something like "SageTVBinaries"...or whatever you kids are calling them these days.

To alleviate Fuzzy's concern, I'm not staging a coup I was just interested to know if Google would host/own a set of binaries for SageTV. If not, then again, not sure there's much value in submitting pull requests to Google, since google could, at their own pace, pull any changes they want from any other stream (instead of us pushing them).

Not that I'm interesting in maintaining a repo for the purposes of hosting builds, but someone is going to have to do it, if we want people to consume SageTV in a non source form

Part of the reason why I'm asking this, is beacuse you made mention of the fact that when you would build SageTV you'd keep the binaries lying around, since they rarely changed between releases, so it was just easier to update the jar, in those cases. I'm thinking that's probably a good plan to simplify the repackaging of SageTV, but, it also means that the binaries are going to get checked into git, and I'm not sure you want binaries pushed to you as a pull request, but they need to sit somewhere, centrally. Hense why I said that a group of maintiners could possibly act as an intermediate for code/binaries. And, to make it clear, I have zero interest in this role, but someone needs to do it.