On Wed, Jun 9, 2010 at 8:46 PM, Rob Lanphier robla@wikimedia.org wrote:
As you know, any time you want to compel someone to do something, there's always the carrot and the stick. One thing I don't like about the way you've phrased that is that is that you seem to be advocating the stick. Am I reading that right?
I'm not clear what you're asking in practice. I don't think Wikimedia should be penalizing people for not making enough wikitech-l posts per week or anything, no. I do think it's reasonable for it to make organizational decisions, like what sort of communication fora are used for developing its software. I also think it's reasonable for it to ask its paid employees to try to treat volunteers similarly to paid people: ask that they try to respond when intelligent questions are raised, maybe review patches, that kind of thing. Some people don't do well in community-oriented jobs, and that's fine; there are an enormous number of non-community-based development jobs available at other organizations.
One undertone that I've witnessed everywhere is that people in open source communities that have a clear organizational "owner" is that there is a very uneven distribution of people who want a peer-to-peer relationship versus a customer-vendor relationship. This makes it really difficult to work out in the public, because some people seem to prefer the trappings of a peer-to-peer relationship (let me in on your early thinking, publish your roadmaps, work in the fishbowl), where others prefer the trappings of the customer-vendor relationship (the customer is always right, the customer is the boss).
Are you talking about people paid by the organization, or volunteers, or users? As far as I've seen, the users and volunteers here overwhelmingly prefer a more peer-to-peer approach. If someone applies for a job at the Wikimedia Foundation, on the other hand, they should expect to be dealing with the community on a day-to-day basis, and shouldn't apply if they don't want to do that. Every development job I can find at http://wikimediafoundation.org/wiki/Special:PrefixIndex/Job_openings has "You must be comfortable in a highly collaborative, consensus-oriented environment" as a requirement.
One thing to consider about the IBM example is that IBM is a company of about 400,000 employees, and was probably in the middle of their "we're spending $1 billion/year on Linux" year when they instituted that policy. They could probably stand to be a little inefficient in the name of insinuating themselves in the community. We're not working with that sort of cushion.
Is vendor-to-customer development more efficient than peer-to-peer in the end? A lot of open-source projects (e.g., Firefox) have as many features as their closed-source counterparts, on a much smaller budget. And of course, Wikipedia managed to become awfully large on a tiny budget, based almost exclusively on community (i.e., non-Wikimedia) contributions. Paid developers get less work done, but you encourage an effective development community. Volunteers don't only do development themselves, they also provide a pool of people to recruit who won't need to spend time getting up to speed when hired.
As someone who currently works from Seattle (and worked on a distributed team in my last job), I also know that long distance collaboration (even in the same timezone as SF) has its disadvantages from an efficiency perspective. Most people have a strong preference for face-to-face communication for collaboration for good reason...it's high bandwidth. Even people who are really good at doing it take some time to figure out how to be effective using only email and IRC; forcing people who aren't good at it is really a productivity hit.
On the other hand, by involving volunteers as much as possible, you get a great deal of free labor. Empirically, this seems like a very effective approach for organizations that don't have much money, like Wikimedia or Mozilla. Open-source software is turned out on far lower budgets than typical commercial software.
My recommendation is to strive to make it incredibly compelling for WMF staff to work out in the community. That means adhering to WP:BITE and WP:GOODFAITH in spades, and reminding each other that we're all on the same team here.
This is exactly what's *un*important. Many of the most community-oriented projects are notoriously vitriolic, while cathedral-style developers virtually always treat even completely braindead users as though they were made of glass. Being nice is a good thing (to a point), but it's not at all essential.
The essential thing is to give developers the ability and the will to contribute. For them to have the ability to contribute, development must all be public and easily followed, even if that results in superficial efficiency hits. How can anyone contribute usefully to the Usability Initiative (say) if they have no idea what the rationale was behind any of the design decisions, because the decision-making was done face-to-face or by phone? That's more efficient for the employees, but sure as heck less efficient for the volunteers.
For volunteer developers to have the will to contribute, they need to be rewarded, and one of the surest rewards is respect. Respect means that they're treated according to their history of contribution. It means that they can object to something and be listened to even if their objection contradicts what some paid people agreed to in a closed room. It means that an established volunteer contributor has more say in practice than a new hiree. It means they make decisions, they don't just give feedback.
That's not to say the burden needs to be solely on you all, but I think "forcing" employees to work in the community is some customer-vendor thinking at play.
I don't understand what you mean by this at all. Neither an employee or an employer plays the role of a customer in any sense here.
On Thu, Jun 10, 2010 at 12:37 AM, Rob Lanphier robla@robla.net wrote:
Um, ok: http://meta.wikimedia.org/wiki/Product_Development_Process_Ideas
Wiki pages can be used for collecting ideas, but I don't think that's important right now. We have ideas, we just need to discuss them to figure out which ones are best. Mailing lists are a good way to do that -- wikis are bad for discussion.