On Wed, Jul 24, 2013 at 11:38 AM, David Cuenca dacuetu@gmail.com wrote:
Erik, if the WMF is supposed to be a global organization there is no need to concentrate all (physical) resources in SF, unless the WMF is acting as the US chapter, then it could be understood that it has to restrict its geographic presence. As I see it, for example there is no impedement to have a WMF Asia in any chosen country of that region with an engineering department dependent on the WMF.
I would like to hear from the legal team what are the challenges of having a distributed presence. It is not a new problem, many international organizations and companies have gone through the process, so there should be no need to invent new solutions.
I'm not a lawyer, so I won't pretend to speak expertly to the legal situations, but in my time on the Communications team I've seen several concrete examples of where it's very valuable to be far from a conflict physically and situated in the U.S. There's the disputed Kashmir maps in India issue (Google and other outfits with offices in those countries have given in to demandshttp://www.businessinsider.com/most-controversial-places-on-google-maps-2013-5?op=1from local authorities to alter maps in a number of cases). What kind of pressure would we get for this file if we had offices in India? http://commons.wikimedia.org/wiki/File:India_disputed_areas_map.svg
The most recent example was with the DCRI in France. Had we had offices in France, I'm not sure the outcome would have been the same; I imagine our leverage would have been compromised.
Of course, there are significant challenges with U.S. laws around copyright, so it's not a panacea, certainly. But I do think it's a very complicated issue.
As you say, there is international staff already, the only thing missing would be a space to attract even more talent while keeping the costs down. Not everyone wants to work from home. Obviuously an external assessment would be necessary to establish what is the size necessary for that to happen and if the benefits outweight the costs.
As for chapters building engineering capacity I see it as something positive, unfortunately only at the reach of the biggest chapters, and with a very local (contry-level) organizational focus, which doesn't help in creating an international work environement.
Micru
On Wed, Jul 24, 2013 at 12:30 PM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Jul 24, 2013 at 6:44 AM, David Cuenca dacuetu@gmail.com wrote:
I don't agree with Romaine's view that it is a cultural problem, but it
is
true that the WMF management seems to prefer to have all development concentrated in SF.
Hardly. About half of WMF's engineering staff is distributed (both inside and outside the US), and we've encouraged and supported software engineering efforts by chapters. I'd actually love to see much more of that happen, and see other chapters build engineering capacity over time. It's legally challenging for WMF to have office presence in multiple jurisdictions, but having independent orgs like Wikimedia chapters build out development teams doesn't suffer from that challenge.
We're an open source project; being able to decentralize effort is our strength. The caveat I would add is that you actually need to ensure that complex projects are resourced sufficiently. Wikidata is a success in part because it's a well-resourced, well-managed team, and the partnership in areas where WMF does need to help was carefully negotiated.
So, which other chapters are up for building out serious software engineering capacity?
Erik
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Etiamsi omnes, ego non _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe