[IAEP] sustaining development

[Simon Schampijer]

On 12/29/2009 01:42 PM, Tomeu Vizoso wrote:
> On Mon, Dec 28, 2009 at 10:51, Aleksey Lim<alsroot at member.fsf.org>  wrote:
>> On Mon, Dec 28, 2009 at 09:30:20AM +0000, Aleksey Lim wrote:
>>> On Mon, Dec 28, 2009 at 09:16:10AM +0000, Aleksey Lim wrote:
>>>> Hi all,
>>>>
>>>> I'm totally n00b in such field and sorry if I'm talking about obvious
>>>> things but what I have in my mind is organizing sufficient
>>>> infrastructure/place/rules/schedules to let various developers meet
>>>> various deployments needs.
>>>>
>>>> It could be like a bank of deployment needs, some needs could be payed
>>>> some not, some came from individuals(who is going to pay or not) some
>>>> from small/large deployments, from non-profit and for-profit
>>>> organizations etc. It's not only about founding developers(via payed
>>>> needs) but it has such benefit.
>>>
>>> In my mind such place(which could be represented in the web by special site)
>>> would be core point of sugar community, at the end all we have is
>>> someone needs. It could be good point to start for newcomers and let us
>>> flexibly organize sugar development process in social(not technical) and
>>> deployment cases.
>>
>> Does someone have successful examples of such efforts, we could borrow
>> their infrastructure/web-engine/etc. ?
>>
>> I think web portal should have low borders for regular
>> users(individuals) and shouldn't be tied to development resources(at the
>> end we can have just links to track/git/etc). Of course we already have
>> sufficient resources like wiki/launchpad/track but they either too
>> common or too unpredictable for non-developers. For example why we
>> decided to use ASLO instead of using plain ftp or wiki pages ala
>> laptop.org.
>
> Yes, I think something like this could work, there exist already sites
> devoted to put together freelancers and employers, though in our case
> I think that an employer would do well by contracting with someone who
> has already some status in the community, there's a good discussion in
> this chapter of Producing OSS:
>
> http://producingoss.com/en/money.html
>
> In the particular case of OLPC deployments, my impression is that they
> (sensibly) want to create local capacity, so they would prefer that
> their people do the actual work. The problem we face is that coding
> the feature is just part of the job, there needs to be maintainers,
> team coordinators, a QA team, etc. Also, some tasks require some
> specialized knowledge in some area that would take too long to create
> locally.

I believe that building local capacity is a step into the right long 
term direction. Local needs, local solutions with the global solution in 
mind -> backstream the changes.

Doing the coding work is not the full cycle of course. Like you said, 
one does need to maintain the code etc. One would think that this comes 
naturally, in a sense: "I have 1.000.000 learners using the code I do 
want some influence on the maintenance as well". I still hope that 
repeating that mantra-like can change this at least on the long run.

While I believe that global funding is not sustainable on the long term, 
I think that certain tasks might be better done by an employee. There 
are tasks that often are not handled by volunteers, either because they 
are boring or they are just too time intensive. Let's call them the 
administrative tasks: organize meetings, API maintenance, design... Of 
course those tasks are of interest too all members (company, deployment, 
school, teacher, parent, learner...), building a community that takes 
care of all of this takes time. And what do you do if people move 
quickly? AFAIK some open source projects do have several people for 
those tasks, might be for a good reason.

BTW: I especially mentioned design above. Often forgotten when it comes 
to development. The design, the concept, the idea is what makes Sugar 
unique. The code is a better prototype ;p We should make sure that the 
design position is a crucial, too.

> What Michael said about non-feature work being carried by volunteers
> on their free time could work up to some point if we had that work
> very well distributed among lots of people with excellent
> communication between them and with good processes to coordinate their
> work. We are not there yet.

Good point. If you have less time, coordination and discipline gets even 
more important. The role of everyone must be clear - and - each of us 
does need less tasks so he can fulfill them.

Btw: I am doing the half-time model at the moment, and though it can 
work it demands a lot. The needs for such a model to work successfully 
are at least defined above: excellent communication between each other 
and good processes to coordinate their work.

> If we get more realistic and look at existing projects such as GNOME,
> companies employ people who have taken responsibilities such as module
> maintenance and team coordination. That's how companies get to
> influence overall development of the project. See the link above for a
> better explanation of how this works.

+1 This is the model that works up to date for some projects.

> My hope is that once deployers have contributed some features and
> their employees have gotten more acquainted with this development
> model, that they will take a step forward and accept those
> responsibilities. My concern is that this can take too long and the
> people with the best knowledge of Sugar may have had to move away
> before then.

Yeah, our qualified resources are thinning out. We need to make sure 
there are different models for people to stay involved. Half time, 2 
hours a week, once per month etc.

Sometimes I think that keeping the project alive like we did (personal 
investment) was a mistake. It might not have shown that drastically what 
needs to happen to really keep this project alive. I think clarity is 
the first thing we need:

You need to take action to keep this alive.

Thanks Tomeu for bringing this up and thanks to everyone for his thoughts,
    Simon