5 ms·

Inside Netflix’s Project Griffin: The History of Roku Under Reed Hastings (2013)

86 points by tim_sw 9y ago

outside1234 9y ago
It seems like this ending was totally predictable at the outset of the project. To me, it sounds like this project was a total hedge against the case that the TV manufacturers didn't play ball and let them ship a Netflix client. It really sounds like a story that was respun at the end such that the development team didn't realize they were jerked around on a chain the whole time and were just a negotiating strategy.
- scyber 9y ago
  Hindsight is 20/20. It may see predictable now, but this all took place 10 years ago. It was a much different market. Clients on TVs? Not even the iphone had "apps" when this decision was made. I doubt they had considered TV "apps" at the time (if anything they were thinking of stbs).
deleted 9y ago
[deleted]
amorphid 9y ago
Title should say 2013. Cool story. I didn't realize Roku was originally a Netflix project.
- sctb 9y ago
  Thanks! We've updated the headline.
kawsper 9y ago
Interesting story, I own a Roku but I had to import one from the US in order to get the latest model. The "Roku Streaming Stick (3600)" is simply not available in the UK for some bizarre reason, I think it is because Roku has a deal with Sky, or some other TV vendor, to not sell it here. And now that I have a US one, I am not able to use some local UK apps on it, but that is the price you have to pay apparently.
kbenson 9y ago
I remember the Roku platform fondly, even if it had some design flaws that left it hamstrung. The biggest of those was the use of a proprietary language for app development called BrightScript. A sort of bastardized VBScript (from what I'm told, as I don't actually know VBScript, but it looks similar), all complex objects that required performance were "components" that you created with a special function, which really just provided a FFI to a system library through an in language object. For example, the video player, or cURL, or different predefined display screen types. The biggest downside to this approach is that the language was slow, and on a fairly low powered device to begin with, that made some things just too slow to be worthwhile. As an example of this, a friend and I released a program called KidPaint, which was a simple paint/stamp program modeled after Tux Paint. Because the channel/app had to small (~$500k), there was very limited space to ship PNg files for stamps, and drawing shapes manually was actually a multi-second process in many cases. The way we found to get around this was to ship PNG shapes that were black with transparent backs, but with the black color defined in the palette block of the PNG. We would copy the PNG in memory, overwrite the color from the palette section with the desired color, write it to ramdisk, and use the screen component to place a PNG on the screen at the right location and with the right rotation. This process, including recomputing the CRC (and without shift operators, there was no bitshifts available), was much quicker than trying to implement deflate in brightscript, since it didn't come with compression components we could load (which would have been implemented as a library). It was hacky, it wasn't quick, but it was right at the edge of usability, so it's what we had to work with. Now, imagine if they had just lifted one of open source the JS engines into the device. They could still have extended it for loading components if they wanted (browsers do stuff like that too), but they could have leverages the thousands of man-hours put into optimizing those engines, plus the many, many different JS modules out there to help build the ecosystem. Instead, we ended up writing our own serialization library, our own JSON parser/emitter, our own TAP testing protocol, a MOP to make complex object creation and management easier, some functional programming helpers, etc. We ended up open sourcing KidPaint and the libraries we wrote under https://github.com/rokudev https://github.com/rokudev originally, but Roku eventually asked nicely for that name since it would be beneficial for them, and we acquiesced. I think the original stuff is available now under https://libraries.io/github/rokudev/librokudev https://libraries.io/github/rokudev/librokudev (maybe? I'm not actually seeing how to access it, and it would be a shame if it was gone).

86 points by tim_sw 9y ago

It seems like this ending was totally predictable at the outset of the project. To me, it sounds like this project was a total hedge against the case that the TV manufacturers didn't play ball and let them ship a Netflix client. It really sounds like a story that was respun at the end such that the development team didn't realize they were jerked around on a chain the whole time and were just a negotiating strategy.

scyber 9y ago
Hindsight is 20/20. It may see predictable now, but this all took place 10 years ago. It was a much different market. Clients on TVs? Not even the iphone had "apps" when this decision was made. I doubt they had considered TV "apps" at the time (if anything they were thinking of stbs).

deleted 9y ago

[deleted]

amorphid 9y ago

Title should say 2013. Cool story. I didn't realize Roku was originally a Netflix project.

sctb 9y ago
Thanks! We've updated the headline.

kawsper 9y ago

Interesting story, I own a Roku but I had to import one from the US in order to get the latest model. The "Roku Streaming Stick (3600)" is simply not available in the UK for some bizarre reason, I think it is because Roku has a deal with Sky, or some other TV vendor, to not sell it here. And now that I have a US one, I am not able to use some local UK apps on it, but that is the price you have to pay apparently.

kbenson 9y ago

I remember the Roku platform fondly, even if it had some design flaws that left it hamstrung. The biggest of those was the use of a proprietary language for app development called BrightScript. A sort of bastardized VBScript (from what I'm told, as I don't actually know VBScript, but it looks similar), all complex objects that required performance were "components" that you created with a special function, which really just provided a FFI to a system library through an in language object. For example, the video player, or cURL, or different predefined display screen types. The biggest downside to this approach is that the language was slow, and on a fairly low powered device to begin with, that made some things just too slow to be worthwhile. As an example of this, a friend and I released a program called KidPaint, which was a simple paint/stamp program modeled after Tux Paint. Because the channel/app had to small (~$500k), there was very limited space to ship PNg files for stamps, and drawing shapes manually was actually a multi-second process in many cases. The way we found to get around this was to ship PNG shapes that were black with transparent backs, but with the black color defined in the palette block of the PNG. We would copy the PNG in memory, overwrite the color from the palette section with the desired color, write it to ramdisk, and use the screen component to place a PNG on the screen at the right location and with the right rotation. This process, including recomputing the CRC (and without shift operators, there was no bitshifts available), was much quicker than trying to implement deflate in brightscript, since it didn't come with compression components we could load (which would have been implemented as a library). It was hacky, it wasn't quick, but it was right at the edge of usability, so it's what we had to work with. Now, imagine if they had just lifted one of open source the JS engines into the device. They could still have extended it for loading components if they wanted (browsers do stuff like that too), but they could have leverages the thousands of man-hours put into optimizing those engines, plus the many, many different JS modules out there to help build the ecosystem. Instead, we ended up writing our own serialization library, our own JSON parser/emitter, our own TAP testing protocol, a MOP to make complex object creation and management easier, some functional programming helpers, etc. We ended up open sourcing KidPaint and the libraries we wrote under https://github.com/rokudev https://github.com/rokudev originally, but Roku eventually asked nicely for that name since it would be beneficial for them, and we acquiesced. I think the original stuff is available now under https://libraries.io/github/rokudev/librokudev https://libraries.io/github/rokudev/librokudev (maybe? I'm not actually seeing how to access it, and it would be a shame if it was gone).