You can't have an OpenWrt branded product, sold by OpenWRrt, for OpenWrt's benefit and have a warranty/liability waiver that would stand in court with respect to intended use, since OpenWrt is the label/certification/intended use in the first place. Furthermore, in many jurisdictions, the importer entity, aka OpenWrt, becomes the legal equivalent of the Asian manufacturer, the intent here is to protect Consumer Rights with local entities that are liable in front of the local law, so Consumers are not stuck enforcing their rights in a foreign Asian court with quasi inexistant rights and expensive foreign court costs.
Like I said, I donât want to go into the vey many intricacies of Insurance and different jurisdictionsâ legal liability requirements/issues, as this would be a different topic for which I am highly qualified, but do not wish to develop as it is now going very much off topic and very much into my day job.
As a Senior Insurance Broker, Insurance Teacher and Certified Risk Manager, I just think the custom OpenWrt certified hardware or White Box label OpenWrt certified alternative present many huge business risks that, if not considered under a fully operating business concern and proper risk management assessment and consideration, can easily conclude as a very expensive failure. At the very least, a seperate legal entity should be considered, as to not jeopardize the open source entity.
Donâ t get me wrong, I really like OpenWrt, but having seen tons of flaky hardware in my career, I really donât think its a good idea.
I think it is good to hash this out and I will counter that others have done this - the pinebook/pinebook pro could be loaded Debian, Arch Linux derivatives and some BSD's. Buyers choice. I also believe that the Pinebooks were largely pitched as development platforms and an OpenWrt router could certainly be in that category.
My recollection is that orders were taken with the caveat that a threshold had to be reached for production. I think there was also a mechanism for refunds, minus handling, if the project did not reach its goal. I also believe that the manufacturing was sub'd out to China.
A group discount for an existing product seems more feasible.
Instead of trying to run a business.
It would be nice if someone found a well supported and likely popular devices to then ask for the retailer to offer a group discount. For example by providing a COUPON code forum members can use when ordering the device.
Obviously these offers might be regional as not too many retailers trade globally.
I like your idea of group discounts. It actually support my suggestion of a select subset of models/family line and support them them to the max.
As for group discounts, it might be easier to work out something like regional coupon reimbursement rebates with the manufacturers.
Maybe Linksys, Netgear or other manufacturers would be interested in working out a deal with OpenWrt.
However, itâs also very difficult to justify a custom design, when the free market decides to reduce price to gain market share or liquidate end-of-line inventories. The custom device would also become obsolete and expensive relatively to liqudated hardware.
For example, these days in Canada the Linksys EA8300 ist going for CAD $130 refurbished, CAD $150 new and the MR8300 $180 new. These devices are very nice mid-level hardware sold much cheaper than their US counterparts, the EA is officially supported and the MR just reached Master Support status :
Even if you found an ODM to do bulk-packaging, was willing to work with you, and passes all the other various and sundry checks, you still have the issue of drivers for chipsets..
If you rope into the officially released drivers, they would probably be closed-source and under NDA. If you eschew official drivers, you are left with the issue of re-creating a closed-source proprietary driver with open-sourced - and has to be done in a sterile development environment (meaning, no one involved can ever have been exposed to the proprietary code source), or you're opening yourself up to a IP legal battle/injunction.
LOTS of things are completely do-able as a one-off, but the moment you attempt to organize, it gets complicated quickly.
Exactly to my point regarding complete workflow Risk Assessment, my Linksys EA8300 and MR8300 use completely rewritten divers from CandelaTechnologies in order to avoid proprietary Qualcomm Intellectual Property. As such, what are the limitations/issues with respect to using drivers IP and any other IP for that mater of fact.
From what I understand, there are very many issues both hardware and software that if properly addressed, would make any cutsom design short lived, uncompetitive and unattratcive to most which are likely to consider going on board with a certified custom mass design procurement.
Honestly, the device manufacturers just don't have to care They aren't held accountable for flaws or updates. The hard-core enthusiast community will always have a need for something like OpenWrt, as the Android community did for custom ROMs several years ago, simply for the choices it offers.
But, doing that on a large-scale, concerted effort?
If for no other reason than I don't know anyone who wants to "volunteer" to field the insane introduction of "Consumer Public" questions because they found a cheap router online. I mean, the forum gets those types from time to time, but as official platform, it introduces a whole new level of policy and privilege, since you'd need full-time moderation staff, and everything that goes along with it.
I understand the concern with Qualcomm firmware. My personal leaning is toward MediaTek. MediaTek is working closely with the Linux Kernel Developers. Of late, upstream MT76 updates have committed to ^Master frequently.
It would be helpful if the OpenWrt developers could debate the strengths and weakness of the different platforms. Could a consensus be reached as far as the platform with the best OpenSource support?
I really like the idea, there are a lot of difficulties as others have pointed out.
Perhaps some sort of "partnership" with an existing hardware manufacturer ( GL.iNet seems an obvious candidate) could be fruitful: Start with one device (maybe 2-3 maximum), where the company works w/ the OpenWRT community to narrow down their components that meet the sweet spot for price vs performance, open source friendly drivers, future availability, etc. The community could "commit" (give an estimate of demand), the company would commit to contributing fixes and such back. Some prototype and finalized hardware would of course go to OpenWRT devs. If the device ends up meeting the goal/requirements, the company can advertise a "Backed by OpenWRT" logo or similar.*(Ideally some percentage or block grant of revenue would go back to the project too.)
*Not to be confused with any sort of official certification. Almost any of this will probably need a lawyer.
@shep
What was your original reason for wanting/proposing this?
Thinking on this a bit more, at root for my desire, and I think for most, boils down to "support". We all want to purchase/use (a range of) devices, and want to know they will be "supported". That is, we want to know the device will work well, and any issues will be addressed. A soft dependency of this is widespread usage: The more people using a particular device (and the components within it), the more likely it will work well. (And tend to get cheaper as well.)
Also we want those that have contributed a lot to be supported/rewarded, even if in just a small way. This also helps ensure the project will continue and be healthy, which feed back into the main concern.
I kinda lucked into having a couple devices that are "well supported" by OpenWRT that enabled them to do what I needed/wanted. I've recently been needing to replace/expand them, and figuring out what new stuff that is "well supported" that meets my needs/budget has not been easy.
Thanks to one kind soul answering my question, I semi-randomly picked a used model off ebay that, specs-wise, should do what I need. How many developers have one? Are actively using/developing against that model? How many people are using that model w/ OpenWRT? I don't think there's much way to tell. It sure would be nice to filter the TOH to my requirements, and be able to see some info on relative popularity, number of devs, etc.
Some combination of tracking download stats, forum posts, polls etc might be able to give insight, but it would take a fair bit of work.
Here is data regarding website / download access, here a discussion regarding collecting telemetry data from Openwrt devices which seems to led to no further actions.
I can understand that, but at the same time the complete lack of information about OpenWrt's active user base is a problem. E.g. in current discussions in the IETF about the side-effects of proposed new AQM schemes, OpenWrt is routinely ignored since nobody has and reliable information about how many active devices we are talking.
IMHO sending a unique (excessively hard to invert) hash somewhere would for me be an acceptable leak of information to which I would opt in.
No, ATM we have nothing, so something like:
SHA512(enumerated MAC addresses of device, salted by the hostname)
should allow to generate a relative stable UUID that will only change if the MAC addresses change or if the hostname changes, both IMHO rare enough to ignore. If an participating router would upload that information (once per week or month, at a time of week defined by the X low bits of the hash to spread the upload times around) OpenWrt would at least get an idea about the current number of active, and participating devices. (Just get the number of unique hashes collected inside the reporting window, so week or months, et voila, a relative reliable lower bound number for active OpenWrt instances)
Sure, stuff like OpenWrt, kernel version would be interesting, but really pale in comparison to get some reliable usage numbers...
OK, maybe I could be convinced that some users feel that releasing some usage data about their usage is harmless from their point of view and useful to the community. However, it would have to be on an opt-in basis, where an additional add-on module not part of release/snapshot version would have to be manually and purposefully installed or packaged.
There could be a bunch of information check boxes, grouped by category or sensitivity of information and you would have an opt-in granular disclosure that could likely convince many to participate, maybe even myself. There could be explanations about the consequences/risks regarding the release of any particular information on a by item or by category level.
Furthermore, since purposefully opted-in, there would have to be an acceptance disclaimer, limitation of liability and all the lawyer stuff acceptance checkbox, therefore limiting OpenWrt's liability in the event of a data/security breach on either side.
I understand this would give an incomplete picture of actual usage, but surely better than no picture at all.
However, I still believe that unless as an opt-in option, in no way, shape or form should any info be phoned home period.
Maybe this thought should be proposed to developers, unless it already has ?
Not sure whether that is a relevant argument, convincing you about the feelings of others is nice, but...
That is a bit extreme, IMHO opt-in seems appropriate but a separate package only if the feature actually has a noticeable size. You need to trust the developers already, so trusting them to not enable that feature without the users consent really just adds one more minor item to the things you need ot trust hem about. But as I said early on, I agree that this feature should be opt-in, as I am certain that opt-out would not fly neither with the developers nor the users (and for my purpose it really does not matter that much).
That IMHO is a potential level 2, only worth discussing after level 1 has been reached...
That is pretty much in the eye of the beholder and really hard to generically solve, hence my proposal to simply forego this level of detail for now.
Sorry, that seems very much over the top. A text like, "voluntarily send anonymous hash of MAC addresses and hostname once per week to a collecting webserver" would IMHO all that is needed. Let's keep that simple. Then again you might be on to something and the General Data Protection Regulation (EU) 2016/679 might make all of that a bureaucratic nightmare and a no-go.
If you only store anonymized data (e.g. only the hash and the data/time it was seen last and not the IP address) that should be a non-issue, but IANAL.
+1.
And no one even proposed a mandatory automatic method, so I believe we all are in violent agrrement here
Well, I guess that they have enough on their plate and should only be bothered if there is a concrete proposal including a working implementation (as proof of principle). @tmomas just as a technical question, could the website/wiki/forum servers be used to receive, aggregate and [present such voluntarily submitted usage data? And more importantly, should they?
I guess that depends on the concept used for submitting such data.
If that concept creates such high loads on the server that it will impact the performance of whatever else is running on the server, I'd say collecting statistics needs to go on a separate server.
Should they present the usage data?
I'd say yes, as long as no problematic data (GDPR) is shown.
They aren't held accountable for flaws or updates. The hard-core enthusiast community will always have a need for something like OpenWrt, as the Android community did for custom ROMs several years ago, simply for the choices it offers.