This is very exciting and welcoming!!! > On Jan 16, 2019, at 10:57 AM, 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] > <mailto:[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 > <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/290A37BE-FEDF-4707-8637-775343917FC0%40gmail.com. For more options, visit https://groups.google.com/d/optout.
