This is very exciting and welcoming!!! > On Jan 16, 2019, at 10:57 AM, Kohsuke Kawaguchi <k...@kohsuke.org> 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 jenkinsci-dev+unsubscr...@googlegroups.com > <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>. > 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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
