Good News. As a user in China, I also hope that more and more Chinese users 
can use Jenkins and participate in the contribution.

On Thursday, January 17, 2019 at 2:57:51 AM UTC+8, Kohsuke Kawaguchi 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/0a4fdd73-53c9-488c-9e8a-a51afd7e2644%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to