Re: [VOTE] Screwdriver.cd


Kohsuke Kawaguchi
 

I'm a little late to the party as I was on vacation. Looks like this topic needs more discussion before we call a vote.

I hear the point from Andy & Tara that, in my understanding, basically boils down to "how does this new project fit with all the other projects?" It's a perfectly legitimate question. I'm imagining that that question is coming from a natural desire of having a portfolio of projects that are complementary and non-overlapping. I certainly share the goal that we amass such projects, so that collectively we can tell a bigger story and make a bigger impact.

That said, in my past experience with open-source projects, it doesn't work very well trying to hand-pick a curated portfolio upfront. One reason is that a healthy competition and chaotic breeding ground is actually pretty crucial to sustain the ecosystem as a whole, aka creative destruction. Another reason is that we cannot predict a winner. Only a market can.

I'm an old timer so I'll start with XML parsers at Apache. Originally IBM donated its code as Xerces, then Sun donated its code as Crimson. There was a period in which they were both actively maintained as separate projects. They had different pros and cons, such as footprint, modularity, etc. Then they decided to do a joint rewrite, which later became "Xerces 2," which learnt from both Xerces 1 & Crimson. I think overall this was great. Because Xerces 1 and Crimson were both under Apache, they knew each other. Features, ideas, and code cross-pollinated. I'm pretty sure that helped building a common sentiment of "why are we duplicating this work?"  After all, every time something changes in XML, they had to do very similar work twice.  If Crimson was not allowed into Apache because it was overlapping with Xerces, then Sun probably would have taken that project somewhere else, and this kind of collaboration wouldn't have happened.

Apache data projects are another great examples. There are so many projects with considerable overlap. That's collective eyeballs of developers at work to kill any blind spots. If there is a master mind committee of Apache data projects that decide who gets in, I don't think the ecosystem would have been as robust as it is. At smaller scale, I see the same thing plays out in the Jenkins plugins. There have been many times where similar, overlapping plugins were produced. We choose quite consciously not to reject duplicates, and instead we chose to encourage those people to meet, talk, and work together. 

I'm a firm believer that the CDF should adopt a similar mindset. We should welcome projects that might disrupt some of our existing projects. And to reiterate the first point, I'm also a firm believer that we should actively recruit projects that are complementary and non-overlapping. Those two goals aren't mutually exclusive.

Tara has the other point around the growth goal. I'm going to look at that next and respond separately.

On Wed, Jul 31, 2019 at 6:29 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:
-1 binding 

(as a 'defer' not a 'deny')

To Andy's point, I also feel like we need better details and transparency around the goals of the existing projects so that we can quantify how any new projects fit into that picture.  Additionally, I'm not sure Screwdriver fits the current descriptions for new projects as defined in the project lifecycle doc around growth goals, at least as currently written.  I'd like to see us get clarify on both of those points before moving forward.

All that said, Screwdriver is a very neat tool with what appears to be a strong core team that is still very much worth of consideration, so it behooves us to figure this out sooner rather than later.  It may well be the perfect project to help us work out the kinks, if you will...

-Tara

On Tue, Jul 30, 2019 at 9:51 PM Avi Kessner <akessner@...> wrote:
+1 non binding.
I saw the screwdriver presentation and it looked really impressive. After the fundamentals are agreed upon I think it could be a great asset.  



On Tue, Jul 30, 2019, 14:37 Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
I am a -1. We (the CDF TOC) haven't (yet) formalized an interoperability plan/strategy for the existing member projects. I think we should clarify how all these projects fit together for the benefit of end users before accepting new projects. I think Screwdriver is interesting and we could all learn from that community, but I'd love to defer adding it (or other projects) until we have a clear story for the founding projects. 

On Tue, Jul 30, 2019 at 12:07 PM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
The screwdriver.cd project has been formally proposed for inclusion in the CDF. The proposal information can be found here: https://github.com/cdfoundation/toc/pull/22

And the team's presentation to the TOC can be found here.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

Dan Lorenc



--
Andrew Glover
Director of Delivery Engineering
Netflix, Inc.



--
Tara Hernandez
Engineering Manager Google Cloud





--
Kohsuke Kawaguchi

Join cdf-toc@lists.cd.foundation to automatically receive all group messages.