<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 20, 2016 at 8:16 AM, Chris Dent <span dir="ltr"><<a href="mailto:cdent+os@anticdent.org" target="_blank">cdent+os@anticdent.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think language does (or should) have anything to do with it.<br></blockquote><div><br></div><div>++++^1024</div><div><br></div><div>Language is what finally forced this discussion (as a prerequisite), now that we're here, lets finish the prerequisite before going back to what got us here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The question is whether or not the tool (whether service or<br>
dependent library) is useful to and usable outside the openstack-stack.<br>
For example gnocchi is useful to openstack but you can use it with other<br>
stuff, therefore _not_ openstack. More controversially: swift can be<br>
usefully used all by its lonesome: _not_ openstack.<br></blockquote><div><br></div><div>Heh, projects usually see this as a positive.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not being in OpenStack (where "in" means "of the product") is good<br>
for OpenStack, good for the project and good for opensource in general:<br></blockquote><div><br></div><div>[excellent list of project attributes removed]</div><div><br></div><div>I would really hope these could also apply to OpenStack projects, and understand why they usually don't.  In or out of the tent, those attributes have at least one strong common thread, the ability to say no when necessary and follow a specific path.  Self-discipline.  In or out of the tent, projects without that disintegrate eventually.  I'm posting that list on the clubhouse wall.</div><div><br></div><div>Since we are, by definition in the mission statement, all things to all people, we got really inclusive in the last year or two.  The pendulum does appear to be swinging the other way however, somewhat due to the costs of scale.  Maybe entry into the tent should come with a ticket price to help defray some of those costs?  Not just direct $$$ (corporate foundation membership), but dedicated X hours per cycle for documentation or Y hours for Infra or Z core/time units of cloud resources.  Wait, we do something like that already?  Maybe its time for a cost-of-living adjustment...</div></div><div><br></div><div>dt</div><div><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>