On Wed, Mar 9, 2016 at 9:58 AM, Saverio Proto <ziopr...@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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
