<div dir="ltr">I really like where you're going here with your ideas.  A couple of things I would want to capture better as we discuss models of success beyond the license attributes that define an open source license. <div><ul><li>I think transparency in community is hugely important. More so than governance. We can have variations on governance from well documented meritocracies (e.g. The Apache Way, The Debian Social Contract) to the undocumented dictatorship of Linux and they encompass a collection of hugely successful open source development communities. So transparency of meeting minutes, email discussions, bug lists, etc. to me is more important than trying to describe the various governance structures.  People see how the community functions regardless of its documented (or undocumented) governance. I think the failure of some of the "modern, corporate" collaborations will be their lack of complete transparency. </li><li>I think we should be careful as we articulate things that are part of an open, collaborative, liberally licensed software development community versus attributes of well constructed software. Software construction discipline (configuration management, version control, batch-oriented recipe driven builds, etc.) is an aspect of all scalable software, regardless of whether developed in highly proprietary closed companies or highly successful open source communities. There are lots of open source licensed software packages on the forges that lack community and lack discipline. There are lots of proprietary products that scale the same as successful communities.  The models for the early tools came out of places like the sometimes very proprietary world of Bell Labs with PWB, make, sccs, etc.  </li></ul><div>I may have poorly stated my initial position on picking a focus (or carefully choosing multiple foci). I was not suggesting the OSD with its licensing attributes couldn't encompass licenses that embody software freedom with its focus on the rights of the user. I was suggesting each definition (OSD and software freedom) was powerful because it picked a focus for its message. </div></div><div><br></div><div>cheers, always </div><div>stephe</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 10, 2016 at 7:08 PM, Luis Villa <span dir="ltr"><<a href="mailto:luis@lu.is" target="_blank">luis@lu.is</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I'm afraid I'm jumping in to the middle of this discussion, not having been part of the initial discussion. I'm going based on what I've seen on the wiki, and the initial discussions we had about this topic 1+ year ago at the board level.<br><br></div>(Overall, to be clear, I strongly support the "beyond licensing" exercise - I think it is critical to the future of OSI and FOSS more broadly. And I support software freedom; I think it is ethically important and am a dues-paying member of FSF, though I would have opposed the addition of "software freedom" to the OSI mission statement had I still been on the board, mostly for the same reasons I'm going to give below.)<br><br></div>(tl;dr: open source's developer-focused pragmatism is related to, but quite different than, any existing definition of software freedom; blurring those distinctions risks losing lots of important context and learnings.)<br><div><div><span class=""><br>On Sun, Apr 10, 2016 at 8:46 AM Allison Randal <<a href="mailto:allison@opensource.org" target="_blank">allison@opensource.org</a>> wrote:<br></span><div dir="ltr"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In fact, software freedom is the direct cause of the practical<br>
benefits of open source. And at some point, those abstract benefits of<br>
software freedom are important in telling the difference between open<br>
source and a license that only shares the source code but doesn't grant<br>
the right to use, modify, and redistribute it. At first glance it might<br>
seem "like open source", but the fauxpen source license only gives you a<br>
fraction of the practical benefits of open source.<br>
<br>
Open source and software freedom aren't two different things, they're<br>
two ways of talking about the same thing.<br></blockquote><div><br></div></span><div>I don't think that's correct; perhaps more importantly for this group, it isn't consistent with a "beyond licensing" approach to open source.<br><br></div><div>Definitionally, the reason why software freedom isn't the same as open source "beyond licensing" should be obvious: no one has articulated a coherent, useful definition of software freedom that goes beyond licensing, so you can't go "beyond licensing" without also going beyond software freedom.[1] More arguably, FSF's freedoms are (correctly!) focused on the freedoms of the <i>user</i>,[2] open source has focused on <i>developers.</i>[3]<br><br></div><div>Practically, I think there are many activities/behaviors that would widely be labeled as "open source" but:<br><ul><li>have nothing to do with licensing/source availability<br></li><li>are not part of "software freedom" as anyone has ever defined it that I'm aware of (i.e., if you failed to do them, FSF would still sign off, but many open source developers would be grumpy)<br></li><li>are being rapidly embraced/extended by proprietary software (so are very relevant to the future of both free and open software, and certainly to the future of OSI)<br></li></ul></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Some examples of these activities, just offhand (don't have time to elaborate a ton tonight):<br><ul><li><b>revision control:</b> historically something done poorly by proprietary software development; brought to the forefront as a best practice, and best tools developed aggressively, by FOSS communities; now assumed by all software (free, open, or otherwise) as a minimum necessary for beginning any development. Nothing to do with freedom per se; widely associated with open source development.<br></li><li><b>publicly-readable bug tracking:</b> key part of non-licensing open source community-focused development; now adopted widely even by <a href="https://blackpixel.com/writing/2012/02/radar-or-gtfo.html" target="_blank">Apple</a>. Nothing to do with freedom or licensing.<br></li><li><b>collaborative decision-making:  </b>So little to do with "freedom" that RMS is used as the posterchild for how to do this wrong. Considered a key part of any healthy open source community.</li><li><b>communication and distributed development:</b> IRC and mailing lists to tie together distributed developers were rare in proprietary software pre-OSS; they're now de rigeur to the point of supporting multiple "unicorns" (Slack and Github).</li><li><b>distributed governance: </b>free software licenses are one mechanism for ensuring distributed governance, but they aren't the only one; this is why you see standards bodies and industry consortia adopting many of our governance patterns, not just (and often not ever) our licensing.<br></li></ul><p>The common theme among all of these, of course, is how developers work together. Doing that right gives you most of the benefits of open source, regardless of licensing. That's why proprietary software is embracing these things pretty wholesale. It's telling, I think, that no one calls these "free" development practices; they're <i>open</i> development practices (<a href="https://github.com/WhiteHouse/source-code-policy/issues/129" target="_blank">recent example</a>). <br></p><p>So, yeah, I think OSI does itself, open development practices, and the broader movement a disfavor by tying itself too deeply to software freedom. When those are (incorrectly) touted as synonyms, important nuance is lost.<br></p><p>Sorry for the brevity - this is an important topic that deserves less force and more nuance, but I'd rather put the issues on the table badly than not at all.<br></p><p>Luis<br></p></div><div>[1] As some of you even saw in person, I've started talking about a non-licensing theory of software freedom myself, but it's very definitely in an overall vacuum: <a href="http://lu.is/?p=2917" target="_blank">http://lu.is/?p=2917</a><br>[2] <a href="http://www.gnu.org/philosophy/free-sw.en.html" target="_blank">http://www.gnu.org/philosophy/free-sw.en.html</a> uses "user" 16 times, developer 6x, "community" 2x <br></div><div>[3] ESR engaged in a lot of revisionist history in old versions of <a href="http://www.opensource.org/history" target="_blank">http://www.opensource.org/history</a>, but one claim that I think was accurate (and left in when I rewrote it) was the statement that OSI grew out of a determination to "advocate for the superiority of an open <i>development</i> process". (emphasis added by me in this email)<br></div></div></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="monospace, monospace">Stephen R. Walli<br>mailto:   <a href="mailto:stephen.walli@gmail.com" target="_blank">stephen.walli@gmail.com</a> <br>mobile:   +1 425 785 6102 <br>blogs:    <a href="http://stephesblog.blogs.com" target="_blank">http://stephesblog.blogs.com</a>  (Once More unto the Breach)<br>          <a href="http://www.networkworld.com/community/walli" target="_blank">https://opensource.com/user_articles/16271</a> (<a href="http://opensource.com" target="_blank">opensource.com</a>)<br>Flickr:   <a href="http://www.flickr.com/photos/stephenrwalli/" target="_blank">http://www.flickr.com/photos/stephenrwalli/</a><br>LinkedIn: <a href="http://www.linkedin.com/in/stephenrwalli" target="_blank">http://www.linkedin.com/in/stephenrwalli</a><br>Twitter:  @stephenrwalli</font></div></div></div></div></div></div>
</div>