
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><span>Hello all, </span></div><div><span><br></span></div><div>Since I'll be in London working on InnerSource on the 21st, I thought I'd spent a few minutes listing the beyond licensing issues that worry me and that prompted me to organize the meeting. I'm also sending my team member Duane O'Brien <<a href="mailto:duobrien@paypal.com">duobrien@paypal.com</a>>, who attended the Summit last month (please send him meeting details)<br><br>1. <b>Transparency isn't negotiable. </b>That means board meetings must have a public component. Board minutes must be published. Decisions (both technical and political) must be publicly documented, and preferably backed by consensus. Although it takes time, public discussion must precede or be a component of major decisions. Donors must be disclosed. What's more, discussions must be publicly archived so decisions can be understood years after they are taken.<br><br>2. <b>Corporations aren't people. </b>I started saying "Open Source is People" a few years ago, as a meme to remind folks that reputation (and merit for good works) should only be achieveable by individual people in FOSS. Good corporate involvement boils down to being a good place for FOSS people to work (because of enlightened policies). Use of corporate commit-bits that hide individual contributors isn't open source.<br><br>2. <b>Open Source people aren't fungibile.</b> For years I've been watching corporations assign and later un-assign large numbers of resources to specific FOSS projects like pieces on a chessboard, and I've yet to see this practice make a project stronger. FOSS is best when it's about passion. Assigned resources are often more preoccupied about serving their corporate masters than about the project at hand. And even if they do manage to form project attachments, the fact that they may be pulled from the project at any time means their involvement is always conditional.<br><br>3. <b>Patronage is key.</b> When I work for a company, they gain my reputation. The cost of that is supporting my pro bono work (I'm currently serving on 3 boards). Many open source people volunteer on boards or in other capacities as they work their way into the meritocracy. Companies need to support this; it's fundamental to open source.<br><br>4. <b>Pay-to-Play can be dangerous, and a commitment to mitigate those dangers is necessary.</b> 100% Pay-to-play boards (or projects who reject worthy code contributions from non-paying entities) are not good for open source. The reason boards must include community elected voting members is that corporate representation isn't invested in the project in the same way. Rejection of contributions for any reason other than technical merit isn't open source. Another version of this is when a company prioritizes their contributions over community ones, even at the code review point. All work deserves the same prompt review, and the queue and review process should be visible.<br><br>5. <b>Technology must come first.</b> In my experience, open source strategies promoted by corporations are rarely about the best technology winning, and that is often evident in the interface to the community. Projects that focus on technology before strategy are generally appealing to more contributors (and the playing field is generally more level in those projects).<br><br>There are probably more, but this is a pretty good start of what's bothering me today :-).</div><div><br></div><div>D</div></body></html>