[OpenWrt-Devel] Request for Feedback - prplwrt Software Support Program - initial draft

[Kathy Giori]

On Wed, Mar 9, 2016 at 9:58 AM, Saverio Proto <zioproto at gmail.com> wrote:
>> I don't have a number off hand, that's still being decided. My feeling has
>> been that's it'd be in the tens of thousands USD total. I'll try to get more
>> of finalized amount as soon as possible.
>
> Hello Eric,
>
> considering that a Senior Engineer in the SF Bay Area has an average
> income of 120.000 USD per year... a contribution on terms of tens of
> thousands dollars does not cover even the work of one person for one
> year. Should we for this little money involve an american foundation
> in the decisional processes ?
>
> My feeling is that prpl is an American foundation that is throwing
> penauts to a successfull open source project to have development at
> low cost.
> A company that hires a team of developer for a Carrier Grade OpenWrt
> spends more than 100.000 USD per year in development cost.
>
> You are right, there is a conflict between the community and prpl, so
> you have to convince us better :)
>
> Best regards
>
> Saverio

Saverio and all,

Let me offer a few thoughts, since I've been involved in prpl since
the beginning, and you can either praise (preferred) or blame me for
initiating the prplwrt PEG. :)

My initial goal was simple -- improved industry-community
collaboration. But my secondary goal, assuming trust relationships
would be established, had also been the idea of funding OpenWrt
developers via prpl. Why not industry direct? Partly not to skew the
project toward one specific vendor, but also because industry-direct
funding to individual developers, or even professional services
companies out of country of the funder, can be problematic
(logistically/legally). I lived through some painful attempts.

It is wasteful to see industry re-invent the wheel in
custom/proprietary or even open source ways, when there are FOSS
solutions to a problem. Sometimes industry isn't aware (shame for not
looking harder), but often they worry about lack of "control". If prpl
could establish the means to collaborate effectively, then we can
discourage industry from either being completely redundant, or from
forking FOSS projects such as OpenWrt (and direct kernel hacks) into
hard-to-maintain dead ends.

Regarding PSSP:

1. Frequency. The PSSP funding cycle as proposed is twice per year,
and that timeline includes the process of bringing forward ideas,
prioritizing them, and then selecting as many implementers as the
cycle of that budget allows. "Big" ideas therefore will need to be
broken down into pieces. For example, with a goal of auto-update, it
may start with a proposed framework or pre-requisite security feature.
An idea for cycle 1 could even be a "study" of various autoupdate
frameworks and options -- a thorough due diligence analysis, having a
reviewed document as the deliverable.

2. Non-exclusivity. There is nothing stopping a prpl member or
non-member business from funding any of the proposed project ideas
outside of prpl. Going back to the "relationship" and collaboration
goal, prpl organizes weekly calls, participates in related industry
meetings, and sponsors face-to-face (plus streamed) OpenWrt Summits.
These are useful to expose industry and community developers to each
other so that they can better collaborate, openly and/or under
contract.

3. Positive feedback. If early funding cycle projects are a big
success, highly valued by prpl members (and the community), then I
would expect that subsequent funding rounds may increase in scope and
budget.

4. Themes. Eric mentioned "carrier grade" features. For example
(courtesy of an HGI member):
a. Network interface diffs between carrier gateways and retail
routers. Multiple WAN, VLANS, hybrid streams, ...
b. End-to-end QoS/QoE. IPTV reliability, network discovery, spectrum
management for LAN/WLAN optimization, inter AP comms, ...
c. Telephony support. VoIP, DECT/Cat-iq, FXS/FXO, ...
d. Network acceleration offload. Common framework for hw and/or sw
based packet processing and acceleration in order to achieve line rate
throughout.
e. Remote mgmt and firmware or software upgrades. Securely. Include
framework for smart gateway -- downloading 3rd party apps.
f. Secure firmware. (Need key management analysis - who holds what
keys?) Carriers want to protect certain resources such as networking
and root gateway management while allowing openness to 3rd party
software and services. Want to convince vendors to enable flexibility
for technologists, tinkerers, and innovators to unlock hardware for
innovation and research, to include full networking stack.
g. Power saving. Newer SoCs have more power control knobs -- invoke a
framework to take advantage of reduced power modes.
h. Automated testing. Already have a start at github.com/qca/boardfarm.
i. Deployment support. Dependency on remote management, but to include
confidence that major kernel upgrades can occur over time, for
increased performance and decreased security risks.
j. App environment. For installing 3rd party software and services.
For example, parental controls, virus protection.
k. IoT hub. More apps/daemons to be installed to keep up with new IoT
protocols and devices. (IoTivity, AllJoyn, ...)

Another initiative, just getting started, is the prpl board farm -- an
automated regression test framework (originally contributed by QCA).
Better collaboration between industry and community around continuous
regression testing (on many different platforms) would be a win for
both sides.

And finally, I'm hoping that prpl will help raise OpenWrt developer
voices, to bring your valuable insight to be heard by industry.
Especially important is the need for upstream Linux kernel development
(all BSP and kernel driver support). Also important is "giving back",
making submissions directly to OpenWrt trunk (or a staging branch if
not ready for trunk). In other words, in addition to upstreaming,
silicon vendor SDK support on top of OpenWrt should be
pushed/integrated with OpenWrt as much as possible.

Hope that helps.
kathy
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel