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.s...@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.mira...@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.den...@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
