Great news for the community! Thanks KK On Wed, Jan 16, 2019 at 7:58 PM Kohsuke Kawaguchi <[email protected]> wrote:
> Ever since our project got our present ‘Jenkins’ name in 2011, we’ve > always been conscious about the governance of this project. It’s a key part > of ensuring the well-being of the project. We’ve not only talked the talk, > but done some walking the walk too, such as team > <https://wiki.jenkins.io/display/JENKINS/Team+Leads>, JEP > <https://github.com/jenkinsci/jep>, and SIG <https://jenkins.io/sigs/>. > > One idea in this space that we’ve discussed in and out is software > foundation around Jenkins. Those of you who came to Jenkins World > Contributor Summit in 2017 might remember Tyler presenting this idea under > the name “Jenkins Software Foundation” (see slides > <https://docs.google.com/presentation/d/1E3sUlRnfG-Dpmj-Lwrse56S0aUY3PBoGlenU5QwYCXg/edit#slide=id.g16abb2ffe7_0_242> > and notes > <https://docs.google.com/document/d/1JSxYNI_RuA8ITlxVmxBdFg1A-sOKz-w7a9tzuPfWmr4/edit#heading=h.hc79wlk2cwzn>), > at the DevOps World | Jenkins World Contributor Summit in 2018 and > afterwards, Tracy has helped continue this conversation (see slides > <https://docs.google.com/presentation/d/1Q-BGZV4H9x0Vo7QsEg-UfT04jQSJ6zuAQXahl9m3iuY/edit?usp=sharing> > ). > > > *Why?* > In a nutshell, the “problems” we are trying to solve here are: > > > - *Limits to current support and services* - Software in the Public > Interest <http://spi-inc.org/>, which currently hosts Jenkins, is a > fairly modest “limited service” non-profit organization. I love what they > do, but we could use more help; entering into legal contracts, setting up > recurring payment that doesn’t go through my own personal credit card. > These inabilities hamper the growth of the project. > > - *High barrier to participation by corporate contributors* - Our > unique governance structure makes it unnecessarily hard for corporate > contributors to come in and feel at home. We aren’t an Apache project, an > Eclipse project, nor a company-owned project like Chef or Spring. We are > just a little too unique to be understood by corporate open-source offices, > lawyers, and pointy-haired bosses. The net result is that we lose out on > their participation and contributions — money and people. I’ve been on the > phone with some of those companies myself, and so has Tracy. > > - *Misperception that Jenkins is owned by CloudBees* - A common > perception error is that Jenkins is a CloudBees project, when it really > isn’t. But this perception is self-perpetuating. We want a long-term > structure to keep Jenkins alive and thriving, and not being tied to the > fate of any single entity is a key requirement. We want more companies to > participate in Jenkins, feel a co-ownership, and push Jenkins forward > together. > > - *Need to coordinated broader community of contributors* - On the > people front, it used to be that the bulk of the forward motion in this > project came from individual plugin developers. Today, where we need to > move forward requires more organized contributors and skills other than > coding. Blue Ocean was a good example. So was Config as Code, where it took > the persistence of two corporate contributors. Pipeline Authoring SIG > <https://jenkins.io/sigs/pipeline-authoring/> to me is another young > example where if you look at the key participants, it really represents > organizations and what they are concerned about. > > - *Raising and using money well* - On the money front, we are not > tapping our ability to raise money, and we lack the ability to use it > effectively. On the few > <https://wiki.jenkins.io/pages/viewpage.action?pageId=65667489> > occasions > <https://jenkins.io/blog/2012/11/15/fundraising-for-travel-grant/> > that we did a donation drive, we have shown incredible ability to raise > money, but I know we can do a few orders of magnitude more. Plus, this kind > of irregular income is difficult to make the most of, because it’s hard to > enter into recurring expenses. Also, without our own legal entity, we lack > the ability to turn the money into what’s most precious — people! > > Given all this, the Jenkins board, CloudBees (as the biggest contributor), > and the Linux Foundation kept exploring this foundation idea beyond those > contributor summits. We have floated some ideas with some of the companies > participating in the ecosystem. Thoughts have evolved, ideas turned into > more concrete plans, and I think it has developed to a point where this is > beginning to look real, and really makes a lot of sense for the project. > > > *What?* > So here are the key ideas/features of the foundation: > > > - We are calling it “Continuous Delivery Foundation” (CDF), and it > will have a broader charter. It will house not just Jenkins but other > open-source projects in this space. Through the CDF, we want to create > open-source solutions collectively addressing the whole software > development lifecycle, to foster and sustain the ecosystem of open-source, > vendor-neutral projects through collaborations and interoperability, then > finally to advocate these ideas and encourage collaborations among > practitioners to share and improve their practices. > > - The CDF will be a sub-foundation under the Linux Foundation, and > it’s somewhat like CNCF <https://www.cncf.io/>, The Linux Foundation > has experience running lots of sub-foundations in different situations, > which will be a great asset. > > - The CDF will have corporate members paying annual dues, which would > create a stable budget hopefully in the range of $100Ks to $1M+, which > translates to infra cost, LF staff that works on the CDF, events and > meetups, travel grants, etc. > > - The CDF will have contributors — you — who may or may not come from > corporate members. The technical decision making continues to be based on > meritocracy— autonomy of the plugins, code review process for core, JEP, > and other established implicit and explicit practices around code do not > change just because of the CDF. Also, when your employer joins the CDF as a > member, you will have an easier time participating in Jenkins more actively > because your organization understands what you are doing better. > > - The CDF will have several decision-making bodies, such as the > governance board, the technical oversight committee, and the outreach > committee. The governance board is ultimately where the buck stops, and if > you look at the Jenkins governance board today, you can see how it’s > possible that technical decision making is separated from this. The > technical oversight committee is for coordination between projects under > the CDF, design a project lifecycle under the CDF. The outreach committee > is for the noise making — events, marketing, advocacy, that sort of things. > > - The CDF will have multiple projects, which are somewhat loosely > connected to the CDF, by connecting the Jenkins governance board under the > TOC in the CDF. What we are suggesting here is that we take Jenkins and > Jenkins X as separate projects under the CDF, as a reflection of the > reality today that these two sibling projects operate differently. > > - As an added bonus, the LF has a legal representation in China, and our > recent experience > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFvfAKco%3DRxJ6jXCmwX39%2ByexfC1s8TZLwGSZ4dTLberQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > suggests this would be helpful. This is just in time for our growing > Chinese community <https://jenkins.io/sigs/chinese-localization/>. > > Also, just to avoid any misunderstanding, this isn’t CloudBees trying to > slowly pull out of Jenkins. As you saw in 2018 > <https://jenkins.io/blog/2018/12/25/year-in-review/>, CloudBees went all > in on many new efforts, and this will continue. This is more of an > aggressive growth play. We want more folks to join the project so that we > can push it forward faster. There’s so much to do!! > > > *Next Steps* > This is really only a high-level overview, but it’s already a lot to chew > on. This plan isn’t cast in stone, this is a multi-party dance to find and > agree on something mutually beneficial, of which the Jenkins project is a > key participant. I know people will need details to get a clearer picture > of what this thing is, and we will provide that soon, but first I’d also > like to encourage people to look at and comment on the big picture, not > just the details — it’s a bit like the difference between commenting on a > JEP vs. commenting on pull requests. > > Needless to say, this is a collective decision for us, one that requires a > significant level of consensus. This email is meant to start that > conversation, and I’m looking forward to it. > -- > Kohsuke Kawaguchi > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4z%2BQzaBc1pDtciKXH%3DMhB3vUR%3DCShiFbwy__2W6eEH_EQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4z%2BQzaBc1pDtciKXH%3DMhB3vUR%3DCShiFbwy__2W6eEH_EQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6PmtWSQPs1gNr7J9G7W7p2QN85ruuYY2Bigg9_rZKx5yQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
