PrplWrt Feed Considerations

From PRPL
Jump to: navigation, search

Description[edit]

A PrplWrt feed is the idea of creating an OpenWrt-based distribution that focuses on the needs of the fixed-net industry.

As such. the feed would:

  • Focus on stability and end-consumer readiness
  • Come exclusively with packages released under permissive licenses, such as Apache 2.0
  • Be driven by agreements and standards decided in Prpl working groups

At the same time, the PrplWrt feed would always be based on the latest OpenWrt release. With patches and contributions of value to the wider community being upstreamed whenever possible. The feed itself, in turn, would act as a sort of upstream for industry features which may include a full TR-069 integration, a carrier-grade IPC or service-sandboxing features.

Scope[edit]

A PrplWrt feed would not aim to be a full enterprise router or gateway OS. Instead, it is a framework to bootstrap the development of such an OS and serve as a solid development platform. Therefore, not every feature required on a carrier or retail router will be available in the feed itself. However, it's open nature would almost certainly ensure that a fitting package can be licensed from multiple software vendors.

Purpose[edit]

PrplWrt is designed to considerably lower the barrier for anyone interested in developing broadband / fixed-net services and software in an enterprise environment. This can mean service companies looking to create the next generation gateway services such as security services, smart firewalls etc. or hardware manufacturers aiming to move from their proprietary in-house architecture to a system based on open components. At the same time it will give carriers and ISPs is reliable basis for investments in broadband value-added-services as it makes the developments viable for use across multiple manufacturers and device generations.

Governance[edit]

PrplWrt should be governed by Prpl's membership. The corresponding PEG should take the lead on collecting feature requests, getting them ranked by importance and a roadmap proposal agreed. The TSC and a product group made up made up of Prpl members should either approve or amend the proposal. In case of amendments the proposal should go back to the PEG for rework.

Components[edit]

Base system[edit]

As described above, the base system of PrplWrt should always be an OpenWrt release.

Required packages & features[edit]

High-Level API[edit]

For the purpose of supporting the high-level APIs, the feed would need to have:

  • uBus
  • UCI

Service distribution[edit]

Many of Prpl's members are working towards service distribution on broadband devices. The packages listed here are necessary to make that happen.

  • opkg
  • Python, JavaScript?

Packages that need replacement[edit]

Not all packages in OpenWrt can or should be used in an enterprise stack. This chapter aim to capture these and categorize according to the reason for their dismissal.

Licensing reasons[edit]

[TBD]

Unfit for purpose[edit]

[TBD]

Life-cycle[edit]

Every distribution or feed needs to be maintained and cared for. PrplWrt maybe even more so as it would be used as a basis for commercial products designed to deliver outstanding customer experience.

Source dontation[edit]

In order not to start from a blank sheet of paper, Prpl is seeking a partner to donate the framework needed to start a PrplWrt feed.

"The framework" means all configurations, scripts and necessary to have a solid enterprise OpenWrt environment. Ideally, this donation already contains some of the packages listed as requirements above and replaces some of the once listed as non-acceptable.

Distribution Maintainer[edit]

After the initial donation, Prpl would, backed by its members, employ a central distribution maintainer or even a team of developers and maintainers. These would take over the ownership of the donated source code, work with the OpenWrt community to establish an upstreaming process and of course with all PrplWrt contributors and users.

Package patrons[edit]

As time goes on, more and more packages will make it into PrplWrt. Hopefully, the different member companies will donate code that is not core to their business and might help along other PrplWrt consumers. Whenever a package gets integrated into PrplWrt, the maintainer staff will look for a patron for this package. This patronage can be in the form of engineering work to maintain, bug fix and upgrade the package or in the form of financial support enabling Prpl to pay a capable consultant for the listed tasks.

Releases[edit]

Based on the roadmap and features decided by the PrplWrt membership and TSC, the maintainer staff will create tasks, tickets and issues in a centrally managed system such as redmine or Jira. Once the tasks are completed and the system passes all quality checks, the maintainers will prepare a new release.

Quality assurance[edit]

[TBD]

Certification[edit]

[TBD]

Commercial considerations[edit]

[TBD]