[IAEP] Communicating project goals and Roadmap

[Tomeu Vizoso]

On Wed, Jul 1, 2009 at 18:18, David Farning<dfarning at sugarlabs.org> wrote:
> On Wed, Jul 1, 2009 at 7:14 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
>> On Wed, Jul 1, 2009 at 00:40, David Farning<dfarning at sugarlabs.org> wrote:
>>> This thread is an attempt to help clean up a couple of issues that
>>> have been cropping up over the past couple of months.
>>>
>>> There have been a couple of instances of suboptimal communication
>>> between different parts of the project.
>>>
>>> Several times recently, external organizations have been looking for a
>>> big picture view of what is happening at Sugar Labs.
>>>
>>> The .84 release was pretty easy to coordinate.  The development team
>>> picked a release date about six months after .82.  The developers
>>> followed the time line pretty well.  Simon did a fantastic just with
>>> just a stick and a handful of carrots as release manager getting
>>> getting the release shipped on time.  The only two external
>>> organizations we worked with closely were Fedora and OLPC.
>>>
>>> With the midterm release of Strawberry, we have seen the importance of
>>> improving communication with more internal groups and external
>>> organizations.
>>>
>>> Internally, we have seen the importance of synchronizing development,
>>> marketing, and the project as a whole's time lines and goals.
>>>
>>> Externally, we have seen a significant increase in external
>>> organization participation.  Several university have express
>>> interested in working with SL.  Several distributions are becoming
>>> more involved. Several new pilots and deployments are participating in
>>> Sugar development rather than just consuming Sugar.
>>>
>>> A first step will be to start working on project and team level road
>>> maps which assign dates and champions to significant events.
>>>
>>> Sugar Labs and each team already have  roadmap pages listed.  Over the
>>> next couple of weeks, I would like to work with the development, SoaS,
>>> marketing, infrastructure teams to create roadmaps and goals.  (This
>>> is not to exclude any other teams participation.)
>>>
>>> Then using iteration and project level goals we can start linking the
>>> roadmaps together.
>>
>> Sounds great!
>>
>> Tomeu
>>
> There is now a very rough draft/outline at
> http://wiki.sugarlabs.org/go/Sugar_Labs/Roadmap .

First of all, you mention several times a "release" but don't specify
what gets released. Also, is the Sugar Learning Platform the upstream
project? What about SoaS? Also, what is "Unified SoaS"?

"Release dates up to and including .86 have been determined by the
development team. Starting with .88, the release schedule will be
determined by the Sugar Labs oversight board."

I didn't knew that the oversight board was supposed to take such
day-to-day decisions. In any case, I hope that the date that the SLOBs
decide for the Sugar Learning Platform is the same as the development
team decides, because otherwise we are going to have a big conflict
here.

I'm not sure this is what you are suggesting, but just in case I will
warn that no one should try to take control on the upstream
development community because that's something that won't work.

People who want to ship products based on open source have this
conflict where they are responsible to control their product and thus
feel compelled to control the open source community around it. That
doesn't work, the downstream community need to understand the nature
of open source communities and either follow the flow or switch to
closed source development.

Yesterday just read an article about it:

http://www.gnomejournal.org/article/72/working-with-upstream-an-interview-with-laszlo-peter

But I'm sure you can read other similar cases in many open
source-related publications.

To summarize: if you want to release successful products based on open
source code developed by the community, your most important tool is
the understanding of the downstream-upstream relationship. If you
don't understand it and try to control the open source community,
either you will destroy this community, or you will be ignored.

It has been quite a bit of work for me to learn this, but once you get
the hang of it is very liberating because you feel yourself as one
more piece of a community of thousands of people around the world. You
need to be patient and respect the schedules of other projects. You
need to be tolerant and learn to respect the processes of the other
projects. You need to be considerate with the needs of your
downstreams because you are also downstream of other projects.

The faster we understand this, the less frustration we'll have.

Regards,

Tomeu

> I'll continue hacking away at it and linking to team roadmaps.
>
> As always, I try to focus on what is fair, sane, implementable as
> starting points.
>
> There is a good change I am wrong and/or missing important bits.
>
> There is a _very_ good chance this is suboptimal.
>
> david
>
> --
> David Farning
> Sugar Labs
> www.sugarlabs.org
>