On Tue, Mar 18, 2014 at 6:08 PM, Faidon Liambotis <fai...@wikimedia.org> wrote: > On Tue, Mar 18, 2014 at 10:47:04AM -0700, Quim Gil wrote: >> * projects we develop that we want others to use and contribute to (e.g. >> MediaWiki) >> * projects others develop and we embed in our architecture (e.g. > >> Elasticsearch) >> * projects others develop and we embed in our processes (e.g. Jenkins) >> >> These projects define our location in the free software map. The health of >> our projects depends on their own health, and also on the health of our >> common links. > > I'm not sure what "embed in our architecture" or "embed in our > processes" means, could you clarify that? > > I see for example that the page has a lot of the shiny stuff (e.g. Lua > is there, but bash/PHP/Python/Ruby are not). Moreover, a few random > libraries are there but others that we take for granted are not (e.g. > librsvg is there, but noone thought of gzip or bzip2; unihan vs. all of > the dozens of fonts that we use, etc.). Not to mention all the hundreds > of absolutely essential tools that we use for system maintenance that > noone ever sees or cares about, from Linux to GNU sed, dpkg, apt etc. > > I think this needs to be clarified and/or scoped a bit better, including > explaining the rationale & motivation behind doing all this work. > > For what it's worth, a uniqued dpkg -l across the production > infrastructure shows 3276 software packages and personally I'd have a > very hard time filtering the list based on what fits in the above > description.
Hi Faidon, Quim made this list in the interest of making us a better collaborator in the free software ecosystem. Here's what today looks like: * WMF developers work primarily on MediaWiki, with limited participation in other software we rely on. We have reasonably robust participation outside participation, but WMF contributors dominate the development * The makers of other software we rely on take a mild interest in the use of their software on our sites. * Outside of MediaWiki, there is very little interest in the other software produced by WMF Here's what success looks like * WMF developers work on a suite of integrated components, some of which WMF is the upstream, and some of which aren't. For most components, WMF developers do not dominate development, and Wikimedia sites are a big use case, but not the only use case * Many popular software projects led by non-WMF employees consider the Wikimedia's use their flagship use case, perhaps even working with us to deploy the latest versions of their software to our site as a means of more quickly getting real-world use of their software. * New WMF projects (beyond MediaWIki and components of MediaWiki) frequently get traction beyond Wikimedia sites and beyond MediaWiki-specific usage Some of the above may look scary (e.g. do we really want outside projects to be deployed like MediaWiki is today?), but we're going to have to be clever to scale up our development to meet the need of building a truly modern website, short of hiring as many developers as Facebook, Google, Twitter, etc have. Assuming this is true, the real questions implicit in Quim's list are: * Which projects are the most important to foster a better upstream relationship with? * Which projects are we the upstream provider? One way of filtering this list is look at the projects for which we've already developed some sort of upstream relationship. Nik is submitting a lot of work upstream to ElasticSearch, so that's why that makes the cut. Faidon, I'm guessing Debian should be on that list. OpenStack probably deserves a mention. Perhaps there are projects that we currently don't collaborate with the upstream, but there would be big benefit for us in doing so. We don't need to get every obscure command line utility that runs on the cluster, but let's identify some high-value targets of upstream collaboration, and get them on the list. Thanks Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
