Hi Steph, first let me apologize. That was supposed to be a private message to Marcus as he requested. On Thu, Jul 6, 2017 at 1:30 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Eliot

this is why we created the consortium and are working hard to make sure that the community can pay its engineers.

I think this is the major disconnect between the consortium and the community. We should be trying to find finding models that reach individual contributors as well as permanent engineers. We have to foster a growing community, not just a solid support foundation. I imagine a community in which individual committers get rewarded according to how much they contribute to the system, not just permanent engineers and those who are building applications upon the system. There are many problems here, but I think there are interesting models. That's why I brought up Elinor Ostrom's work. But I do apologise. i didn't want to have a discussion here only suggest some relevant ideas for Marcus' talk.

Now marcus is probably looking for feedback patterns in the dev process, idea generation process.

And while this is necessary, it is not sufficient. We have to find ways of bringing resources into the community so that people can make their living by participating. Right now we're at the mercy of external funding, be it employers like mine who are willing to allow me to participate, the French state who is willing to fund related research, and contributions from the consortium form those that are either using Pharo or supporting it. But these funds flow very unevenly and only reach the fortunate. So there is no economic structure which allows for people to stay in the community. They have to secure their own sources of funding. I find this most unsatisfactory. Those contributors who write foundational code (tools, compilers, interface libraries, guis, etc) get no reward, while those who have managed to sell applications get revenue, but I see no fair means of monies getting to those contributors. So there is no incentive to contribute other than if it enables one's business. I myself am collaborating with colleagues to build this kind of business and if successful will contribute back to the community. But I imagine a better structure, one in which the community is able to receive and channel funds to contributors as we, as a community, see fit. Note that there are many kinds of contributions, some here are potential: - writing code for the base system - providing web presence (portal sites that provide documentation and a face for the community (Pharo.org), and automated builds) - tutorials and documentation, be they textual, video, code, etc - marketing (success stories, white papers, promotional material, funding for attending foreign conferences, etc) - educational support (helping universities and schools use the system for teaching) This implies some sort of broader government in which many state holders can participate (hence Elinor Ostrom's principles). What we have now in the Pharo consortium is good; it is functional; it provides things that benefit the community. But it has limitations. Marcus is asking for patterns to make the community grow. I think the economic pattern same should be explored; in fact, I think it is key; more important than the technical work flow. If we truly want the Pharo community (and in my case, Smalltalk communities) to flourish we have to do more than we're doing at the moment. And just as it takes many years to build a technical solution as string as the one we have, it may take many years to build a new kind of economic framework in which open source software can provide benefit, both to its users and its creators. We won't invent such a future by thinking that what we have now is good enough.

Stef

On Thu, Jul 6, 2017 at 6:53 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

Hi Marcus,

as you know I, and others, think the most important thing is analyzing the community economically and trying to increase the flow of resources into the community and keeping people and their skills in the community. If we do not get on a growth path we are small enough that we will wither away. Some of the best contributors have left to work elsewhere, typically for google.

Elinor Ostrom's ideas on managing the commons are the most relevant patterns here. They provide for a community that is just and stable and have been observed and abstracted from human systems that have been healthy for many centuries.

_,,,^..^,,,_ (phone)

...

On Jul 5, 2017, at 2:26 AM, Marcus Denker <marcus.denker@inria.fr> wrote:

Hi,

I want to do a third talk at ESUG as the “part 3” of the feedback loop series.. The first parts where:

1. Nomads do not build Cathedrals: https://www.slideshare.net/ MarcusDenker/2014-esugcathedral 2. Perfection and Feedback Loops: Why worse is better. https://www.slideshare.net/MarcusDenker/perfection- feedback-loops-or-why-worse-is-better-65540840

The idea for part 3 is to do something along the lines of “patterns to enable feedback loops”, a more practical view on what one should be doing (or not be doing) to enable and sustain a project as a feedback loop.

- both things we do and those we should - things that we do wrong / anti patterns - technical as well as social (community…) - examples you have seen in the real world

The idea is not to follow a formal patterns language, it will be informal… so if you have any ideas, please send a private mail to me.

Marcus

-- _,,,^..^,,,_ best, Eliot