On Jan 16, 2019, at 10:57 AM, Kohsuke Kawaguchi <k...@kohsuke.org
<mailto: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.
