docs/principles.rst

   1 *******************************************
   2 Linux Foundation Networking Fund Principles
   3 *******************************************
   4
   5 LFN (Linux Foundation Networking Fund) is the shared home of previously
   6 independent communities with different backgrounds and histories. Each
   7 community has valuable lessons and practices to share with the others. The goal
   8 of this document is to find consensus on a common set of principles based on
   9 these experiences, to better forge a healthy community and meet the needs of
  10 all projects within LFN. This is a living document that future TACs should
  11 improve on.
  12
  13 Autonomy of Projects
  14 ====================
  15
  16 Each LFN project is a self-governing community that is responsible for the
  17 project and creates its value. Each project knows best how to accomplish its
  18 mission, and can do so best by being supported but largely left to act
  19 autonomously.
  20
  21 Each LFN project has a governing body such as a TSC. The role of LFN is to
  22 support projects' governing structures, not to burden them with excessive
  23 governance. When at all possible, decisions should be made by projects
  24 themselves, not the LFN.
  25
  26 Because we give projects lots of responsibility, and support them from LFN's
  27 finite resources, we have high expectations for projects. When we consider
  28 accepting new LFN projects, we want to be sure that they have a healthy
  29 community and are on the right track for success.
  30
  31 Contribute Upstream
  32 ===================
  33
  34 Organizations that get value from projects should give back to the upstream
  35 projects they get value from. Organizations that take without giving put the
  36 long-term sustainability of the project at risk.
  37
  38 Ultimately, contributions take the form of human time. Organizations that get
  39 value from projects should contribute human time upstream, either directly via
  40 upstream contributions or indirectly by paying other organizations that
  41 contribute upstream.
  42
  43 Cross-Project Integration
  44 =========================
  45
  46 A major advantage of LFN is the cross-project collaboration it enables. From
  47 a technical standpoint, cross-project integration is a key element of enabling
  48 cross-project collaboration.
  49
  50 Cross-project integration may take the form of Continuous Integration/
  51 Continuous Delivery pipelines connecting projects. These provide well-tested,
  52 recommended ways to deploy integrated projects, both in test and production
  53 environments. CI/CD pipelines can also enable quick feedback for developers
  54 about how changes in one project impact other projects, enabling quick, easy
  55 cross-project development.
  56
  57 LFN should encourage projects to develop cross-project integrations.
  58
  59 Diversity of Committers
  60 =======================
  61
  62 The diversity of projects' committers is important for projects' health.
  63 Projects should strive to develop a set of committers from various
  64 organizations, not dominated by a single entity. Preventing a project from
  65 being dominated by a single interest gives confidence that contributions will
  66 be welcomed even if they do not align with the priorities of a dominant
  67 interest. This is a key element of ensuring stable long term growth of projects
  68 and attracting contributions.
  69
  70 Diversity of Contributors
  71 =========================
  72
  73 Thriving Open Source projects should have contributors from a diverse set of
  74 organizations. This prevents domination by a single entity, results in projects
  75 that can be more easily extended as they are not designed from a single
  76 viewpoint, encourages following an upstream-first development model and gives
  77 downstream users confidence that they can work with a project, not just a
  78 company.
  79
  80 Listen to Users
  81 ===============
  82
  83 A project's user base is key to its success. LFN should encourage projects to
  84 proactively develop their user base and take user feedback, especially from
  85 users with real deployments, seriously.
  86
  87 Users of LFN projects should contribute to LFN projects by giving feedback,
  88 sharing what they have learned, and clearly explaining their challenges.
  89
  90 Marketplace of Ideas
  91 ====================
  92
  93 The goal of the Linux Foundation Networking Community is to promote development
  94 and adoption of the Open Source Networking ecosystem. The ecosystem will take
  95 the form of a marketplace of ideas, not a single reference implementation. It
  96 is not our job to select one solution or one single stack.
  97
  98 This principle does not suggest that we should be entirely laissez faire. Doing
  99 so can be wasteful of community resources, counter productive and may result in
 100 multiple poor quality solutions. It does mean that we do not automatically
 101 reject projects because they are overlapping or competing when different design
 102 choices or market segments are being explored or addressed.
 103
 104 Open Governance
 105 ===============
 106
 107 Open Source projects should be governed openly. Governance policies should be
 108 clearly defined and publicly, prominently available. Governance systems should
 109 be designed in the open, with input open to everyone.
 110
 111 Although it is typically not possible to start an open source project using
 112 community-elected governance, as there is not a community to elect leaders
 113 from, projects should transition to a community-elected model as soon as
 114 possible.
 115
 116 Open Source Tooling
 117 ===================
 118
 119 Open Source projects are only as Open Source as the tooling required to develop
 120 the project. Using non-Open Source tooling makes Open Source projects less
 121 Open Source. LFN should encourage projects to depend only on Open Source
 122 tooling whenever possible.
 123
 124 In some cases, the productivity increase from using non-Open Source tooling may
 125 justify the loss of openness incurred. However, the choice to use non-Open
 126 tooling should not be made lightly, and the loss of openness incurred should be
 127 taken into account.
 128
 129 In all cases and at all times choice of tooling belongs to the projects. At no
 130 time may choice of tooling be forced from outside the projects.
 131
 132 Projects First and Only
 133 =======================
 134
 135 Supporting the projects within LFN is LFN's primary concern. Supporting
 136 projects to achieve their goals is the best way to support Open Source
 137 Networking and the networking industry.
 138
 139 Projects are the entities that get things done in LFN. Whenever possible, work
 140 should be done within projects, not LFN. LFN itself should remain a lightweight
 141 layer for collaboration among a set of projects. LFN may organize committees or
 142 working groups to facilitate collaboration.
 143
 144 Public Tooling
 145 ==============
 146
 147 All tooling should be public and accessible to anyone. Additionally, the public
 148 tooling should be the primary tooling used for development.
 149
 150 Examples of tooling that should be public:
 151
 152 * Bug tracker
 153 * Chat tooling
 154 * Code repository
 155 * Code review
 156 * Continuous Integration tooling
 157 * Documentation
 158 * Mailing list
 159 * Meeting calendars
 160 * Meeting minutes
 161
 162 Upstream-First
 163 ==============
 164
 165 Open Source projects typically work best when contributions are driven in the
 166 upstream project, using upstream discussion channels to build consensus and
 167 upstream code review tooling to iterate on proposals.
 168
 169 The inverse, developing changes downstream and then "throwing them over the
 170 wall" to the upstream community, is typically fraught with problems. Diverse
 171 stakeholders in upstream communities typically bring viewpoints that result
 172 in changes that are more generically applicable, do not assume the specifics
 173 of the downstream's implementation. Maintaining downstream-only changes can
 174 result in costly rebases to consume new upstream changes, or falling behind
 175 upstream. Working upstream enables a culture of "collaborate on building
 176 together", which is materially better than "build things in silos and
 177 collaborate on combining them".
 178
 179 On rare occasions it may be acceptable to develop code downstream and then
 180 push it upstream. For example, many new projects are seeded with ideas that
 181 started downstream.
 182
 183 Specific upstream-first practices include:
 184
 185 * Upstream code review is the primary forum for developing code, giving
 186   feedback. Patches almost always require iterative feedback/fix cycles.
 187   Large patches in particular often require input from many people over a long
 188   period before they are ready to be merged. Large patches merged without
 189   iterative feedback, especially by people from the same company, will raise
 190   red flags.
 191 * Large features should be planned publicly, with community input.