Those are interesting news. Are we expecting to partner with existing
communities around existing CD projects as a part of CDF? Are some of
them on board with this vision or do we expect they will join us
provided this turns out to be the right way to go? My concern is the
“Continuous Delivery Foundation” feels pretty general and while getting
under the wings of Linux Foundation is an impressive recognition of what
we have achieved, it would be unfortunate to make an impression of
claiming the whole field without wider consensus.
On 16/01/2019 20.01, Marky Jackson wrote:
> This is very exciting and welcoming!!!
>> On Jan 16, 2019, at 10:57 AM, Kohsuke Kawaguchi <k...@kohsuke.org
>> 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
>, 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
>> and notes
>> at the DevOps World | Jenkins World Contributor Summit in 2018 and
>> afterwards, Tracy has helped continue this conversation (see slides
>> 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
> 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
>> 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.
>> 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
>> suggests this would be helpful. This is just in time for our
>> growing Chinese community
>> Also, just to avoid any misunderstanding, this isn’t CloudBees trying
>> to slowly pull out of Jenkins. As you saw in 2018
>, 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-de...@googlegroups.com
> 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-de...@googlegroups.com
> To view this discussion on the web visit