Olimex could be a prospective partner: https://www.olimex.com/About/
They are a small-middle sized Bulgarian hardware company selling a variety of open-source and open-hardware designs. They even have an IoT offering, a cheap board, but powerful enough to run a networking stack, sensors and a relay: https://www.olimex.com/Products/IoT/ They can produce boards and products in batches of hundreds/thousands, as far as I gather, given lead time. They could be well aligned with Mozilla's objectives and new pivot. Jobava On Fri, Dec 18, 2015 at 4:19 PM, David Rajchenbach-Teller < [email protected]> wrote: > I agree that at this stage, we should target third-party > hackers/tinkerers first. Chances are that they are the ones who are > going to innovate with Firefox OS. > > However, we must understand that targeting a Raspberry Pi probably means > that we are not going to have a product for end-users before a few > years, which also means little leverage on the industry. If this is not > the objective, we need to start thinking about partnerships soonish. Of > course, at this stage, we can think of partnering with start-ups which, > imho, would be much healthier than partnering with giants. > > Cheers, > David > > On 18/12/15 15:04, Wilson Page wrote: > > On Thu, Dec 17, 2015 at 8:07 PM, Jim Porter <[email protected] > > <mailto:[email protected]>> wrote: > > > > Improving Ease of Adoption > > -------------------------- > > > > First, I think the most important thing we can do right now is make > it > > easy for people to run Firefox OS on their TV. We can't expect > > enterprising hackers to go buy a Panasonic TV with Firefox OS if they > > want to contribute; we need an easier way. The Raspberry Pi would be > a > > great solution here. First, it's very cheap ($35); second, you can > > already install other media centers onto it (Kodi), so we know it > should > > meet our hardware needs; and third, it's already got a very active > > developer community. > > > > > > Agreed. Barrier to entry is way to high. The only party that benefits > > from baking an OS into the TV is the OEM as they can sell new hardware > > when the OS gets clunky. It would be better for Mozilla and users if the > > OS was portable and could run on any TV/monitor. > > > > I don't think we should be thinking of TV as anything other than a dumb > > monitor. Which OS is projected onto this monitor is the user's choice > > and they should be free to change it and move it to new hardware. > > > > If we're serious about putting users first, we should give them choice > > and protect them from lock-in. > > > > The "Holy Grail" of Media > > ------------------------- > > > > In media center development, people often talk of a "holy grail": > > completely unified media content from multiple sources. If I want to > > watch Jurassic Park, I don't really care where the video comes from > > (Netflix, Hulu, somewhere locally, etc); I just want to watch the > movie. > > One way we could handle this would be to expand the "Rocket Bar" to > > allow searching inside of individual apps. Apps could provide an > > endpoint to respond with search results given a particular query, > which > > we'd then aggregate into a single list. That would make it easy to > find > > content, no matter where it is.[1] > > > > Another, more-thorough way to handle this would be to turn each media > > provider into nothing more than a data source that populates some > > system-wide database. This would be even more content-focused, but > would > > require us to be able to scale up to truly massive amounts of > content. > > > > Unfortunately, most of the major video providers (e.g. Netflix, Hulu, > > Amazon) are *very* concerned about controlling users' experience. > They > > want to be able to plaster their logo on the screen as much as > possible, > > and to ensure that they can advertise all their other shows so they > keep > > you around longer. Netflix in particular enforces this through a > closed > > API and DRM-protects all their videos. This means we have to rely on > > Netflix to provide an app for our platform; hopefully, the fact that > > we're just Gecko under the hood will make this easier (although I'm > not > > sure how EME works on a real device). > > > > Local Content > > ------------- > > > > Because of the restrictive nature of most video streaming services, I > > think it's very important for us to be able to play locally-stored > > media, either on the device itself or on some other device on your > LAN. > > Many users already have local content (especially music), and we > should > > let them play that. It's also an important part of upholding the > Mozilla > > Manifesto: the Manifesto makes it very clear that we should enable > users > > to control the content they consume. One of the best ways to allow > for > > this is to let them control the media files themselves; this also > helps > > us to support smaller media providers like Bandcamp and VHX that > > typically provide their media as downloads. > > > > This could also tie in with Fabrice's "FoxBox" idea; however, I don't > > think we should *require* pairing our media center platform with > another > > device of our making. Users should be able to use any device that > uses > > common media/file-sharing standards. That means supporting some > > combination of UPnP (aka DLNA), Ampache, SMB, NFS, etc. > > > > Enriching Content > > ----------------- > > > > As an extension of local content, we'll want the ability to "enrich" > > that content by downloading additional information about each video. > > (Unlike audio content, videos very rarely have metadata stored within > > the file, and usually the only information you have is in the > filename). > > Software like Kodi has already established a great way forward here: > > content scrapers. There are a bunch of websites out there that > provide > > information about media that we could use to pull in things like > movie > > posters, plot summaries, cast and crew lists, etc. Here's an example > > (the default movie scraper in Kodi): https://www.themoviedb.org/ > > > > Centralizing Media Playback > > --------------------------- > > > > If we're creating a device centered around media playback, it might > make > > sense to move the core playback code (as well as queuing) into the > > system app. This would let us manage *all* video/audio in a central > > location, and allow for things like queuing up videos from different > > sources so they play one after the other. This is a nice feature if > > you're hosting a party. I'm not sure how we'd handle videos on > ordinary > > websites, though; we don't have a way of knowing what *kind* of > content > > they are. > > > > Remote Control > > -------------- > > > > In my experience using media centers, it can be pretty convenient to > > control the media center via a touchscreen-based remote (read: an > app on > > your phone/tablet). I believe we already have a basic remote like > this, > > mainly for navigating webpages, but we should expand this to allow > > controlling playback, navigating through lists of content, etc. We > could > > easily make this cross-platform by just hosting a webpage from the TV > > that other devices on the LAN can connect to. FlyWeb would make > > discovery even easier. > > > > It would also make sense to provide something like a JSON API so that > > people could write their own remote control apps, and do other > creative > > things. However, that's probably not necessary in the short term. > > > > Conclusion > > ---------- > > > > The above points are the main design-related things that I think we > > should focus on. There are lots of other things that make up a good > > media center (e.g. age-restricted profiles so your kids can't watch > > R-rated movies), but I've tried to cover the most important ones. > I'll > > hopefully be following this email up with a more > implementation-oriented > > message that talks about what APIs people expect out of devices like > > this, etc. > > > > - Jim > > > > [1] This is actually what the Xbox 360 does with its "Bing" search. > > _______________________________________________ > > dev-fxos mailing list > > [email protected] <mailto:[email protected]> > > https://lists.mozilla.org/listinfo/dev-fxos > > > > > > > > > > _______________________________________________ > > dev-fxos mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-fxos > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
