A More Inclusive Community-Based Model for Squeak Development

Kamil Kukura kamk at volny.cz
Mon Aug 16 22:15:57 UTC 2004


    I must also thank to Ned for getting light on this issue. I feel the 
future of Squeak is now entirely in the hands of community. I think 
there is really strong affection for Squeak and power plus wisdom of 
community can help Squeak much to be alive and well.

stéphane ducasse wrote:

> - I think that a lot of people are busy and that having real target 
> and task forces to achieve them is missing. The targets I have in mind 
> are: clean the kernel, cut the image, write tests.....
> This is why I found the effort of goran and people having fun with him 
> in the NTFR effort worth and should repeatable.

There's one thing to notice. In worlds of Java and alike they are used 
to settle on ideas in the form of writing specifications which result 
into what they call /interfaces/. Implementations just follow if they do 
at all. However, in our house I think we have more natural approach for 
evolution idea => reality. First we write something small and 
experimental, then it goes into cycle of enhancement/refinement and 
after all it is finally refactored to some degree of abstraction. As the 
result, we got *something*. For example, there's class HTTPClient which 
is used at some places. However, newer versions of BFAV are using 
something different: SptHTTPRequest. Now, it's really possible that 
HTTPClient will die by some time and SptHTTPRequest will mutate to 
better fit into the system, who knows.
So I guess, this should be taken into account if we are going to set 
some "todo"s. I am thinking about establishing some /guides for 
intentions/. As soon as some piece of /something /is growing and is seen 
by community as vital thing to have, i.e. there's general will for 
having it survived, then there should be [community's] feedback in form 
of help to keep it alive. I here mean having maintainers, setting 
working groups, providing financial and technical support, etc.

> - Now we have time and money as variables: we should invent a way so 
> that people having some
> money can pay people to maintain/improve their packages. I want to pay 
> to get a better monticello
> because this way I will be faster and avi will have more time to work 
> on monticello. I'm not saying that people that are willing to give for 
> free their work should not be able to do it, I mean that I would like 
> to pay.

Maybe this paragraph triggered my Mozilla Thunderbird to resolve your 
mail as spam :) But definetely, money is very crucial question. If the 
foundation is up to have fundraising activities, we should help Squeak 
to get in between real people, to have more success stories with it and 
give it a try as how strong will it stay in real world.

> I think that Squeak should get engineering practices (this is what you 
> say between the lines).
> Using well-known practices. Now what do we do? Where do we start?
>
> Stef

In spare time I work on clean-up/enhancements for Socket and its family 
arround (Network-Kernel). I would like to join some working group that 
would be formed for these networking issues. I believe that having good 
networking, we can bring Squeak to production environment which is able 
to give "a reward" in turn. That is some money back to community.
Having the axis:

generalization << === >> specialization

I would like to see more working groups in specialization direction such 
as Standard-GUI working group cooperating with Morphic-Maturing group 
and so on. In contribution to generalization, I would like to see some 
effort toward /constitution/ of Squeak. That is providing adherence to 
ANSI and other solid standards, researching virtual machines, heading 
for stability, etc.

Those my two cents..

-- 
Kamil Kukura

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040817/71f9f9db/attachment.htm


More information about the Squeak-dev mailing list