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:
--
Kohsuke Kawaguchi
|
|
|