What does it take to buy in to Squeak (was RE: Stef's departure from the SqueakFoundation board)
From: David T. Lewis I really don't know how the board would be able to accomplish this without pissing somebody off. A strong benevolent dictator would be required, and we do not have that.
And this is a central issue. Look at the big OS efforts - Linux, Perl, Python are examples. Each effort formed around a central figure that matches David's view of a strong benevolent dictator.
We had dictators, arguably benevolent, in SqC. We have had a power vacuum since SqC dissolved, with no person or group strong enough to carry the community with them - indeed, with some members of the Squeak community hanging on every word out of Alan Kay, Dan Ingalls and the rest of ex-SqC and treating those with greater reverence than the present board.
Unless we have a shared vision of where we're going (difficult with a mature system like Squeak as it can be used in so many ways) or a person/group to act as a proxy for our strong vision (there's no evidence the community regards SqF in this way), we'll fragment as a community. I don't know how to get to the shared vision or the trusted person/group from here, and I expect the Squeak community to fragment. Parts will coalesce around strong projects such as Croquet and Spoon, if the Croquet group are open enough to allow the developer community to grow and if Craig is willing/able to accept distributed developer assistance. Some newcomers will come in, especially around projects that are newcomer-friendly. The rest will probably drift to other systems over time.
Here's an interesting question for the list members: what would it take for you to "buy in" to a central governance model for Squeak? What would it have to look like, who would have to be in it, what would it have to be doing?
My answer to the above (so that I'm not posing questions in the abstract): to buy in to a central governance model, it would have to be taking Squeak in the direction of a fast, modular, cheap runtime with good development tools; it would have to involve or have stated buy-in from my perceived major players in that arena (Bryce for Exupery, Craig for Spoon and Naiad, Tim for VMMaker, plus an appropriate module system and archive such as SM2 + MC2); and it would have to be committed to regular, incremental releases of the smallest possible core plus a cloud of modules that are allowed to be behind the bleeding edge.
As always, my £0.02.
- Peter
On 8/19/06, Peter Crowther Peter@ozzard.org wrote:
Here's an interesting question for the list members: what would it take for you to "buy in" to a central governance model for Squeak? What would it have to look like, who would have to be in it, what would it have to be doing?
Here's another question: why would you want a central governance model for Squeak?
As I've been advocating for years, I'd *like* Squeak to fragment. A children's Squeak, a 3D platform Squeak, a web developer's Squeak, a Win32 app developer's Squeak, etcetera.
So, all I can see SqF doing is to make sure that people don't duplicate too much work, by defining some minimal core, and maybe a clearing house for patches or something like that. But certainly not some sort of central governance model - let the bits of community organize themselves, it seems to work just fine...
On 2006 August 19 15:49, Peter Crowther wrote: snip:
Here's an interesting question for the list members: what would it take for you to "buy in" to a central governance model for Squeak? What would it have to look like, who would have to be in it, what would it have to be doing?
As one of about 300(?) people who voted the SqF members, I'd say that each of us "bought in" the program of each of the Squeak Foundation board members (by voting for our candidates).
But, as the choice was about 7 members out of 9 candidates (BTW I just unsuccesfully tried to find a page on squeak.org listing the board members), and only few candidates provided an "agenda", I will try to be more specific in answering your question ("The Board"="The central governance model you ask about that I'd buy in"):
1) "The Board" would start with defining what Squeak is - "Squeak" as a small "SqueakCore" plus "Packages" - Unfortunately I can only be intuitive here, not saying I know what should be in "SqueakCore", likely it would be much smaller than current Squeak, without Morphic, MVC (UI loadable, is that possible?)
2) "The Board" would steer the community to achieve separating the "SqueakCore", and promote _tools_ that help achieving the separation, and "re-loadability" of some most important packages.
3) Once the separation is done, "The Board" would be repsonsible for steering "SqueakCore" _only_.
4) At this point, "The Board" would _promote_ forking SqueakCore into "BackwardCompatibleSqueakCore" and "ExperimentalSqueakCore" , and promote and work on tools that would enable porting packages from "BackwardCompatibleSqueakCore" to "ExperimentalSqueakCore". - The "ExperimentalSqueakCore" would be: - based on Spoon - support Tweak loadability :) - maybe as Goran suggested use Pepsi as VM :) - Chances are that, at this point, multiple "ExperimentalSqueakCores" would be created, forking the core further, hopefully some forks would merge and fork further, and so on, creating multiple "Boards", which of the forks would retain the honour to be named Squeak .. maybe there would be SqueakSmallland, SqueakSqueakland, SqueakDevelopers etc.
milan
My answer to the above (so that I'm not posing questions in the abstract): to buy in to a central governance model, it would have to be taking Squeak in the direction of a fast, modular, cheap runtime with good development tools; it would have to involve or have stated buy-in from my perceived major players in that arena (Bryce for Exupery, Craig for Spoon and Naiad, Tim for VMMaker, plus an appropriate module system and archive such as SM2
- MC2); and it would have to be committed to regular, incremental releases
of the smallest possible core plus a cloud of modules that are allowed to be behind the bleeding edge.
As always, my £0.02.
- Peter
Milan Zimmermann milan.zimmermann@sympatico.ca writes:
- "The Board" would start with defining what Squeak is - "Squeak" as a small
"SqueakCore" plus "Packages" - Unfortunately I can only be intuitive here, not saying I know what should be in "SqueakCore", likely it would be much smaller than current Squeak, without Morphic, MVC (UI loadable, is that possible?)
- "The Board" would steer the community to achieve separating the
"SqueakCore", and promote _tools_ that help achieving the separation, and "re-loadability" of some most important packages.
- Once the separation is done, "The Board" would be repsonsible for steering
"SqueakCore" _only_.
Sounds good to me. I would like to see a body organizing Squeakers more than anything else, and this is the way to do it. I wouldn't put it so strongly, though: in addition to arbitrating the maintenance of the core part, there is a place for helping people exchange their Squeak addons.
Also, Squeak would continue to evolve the Squeak we know. Discussions about tossing it and starting from the ground up are interesting but off topic. If you want to do that, then you are free, but Squeak's organization should take care of Squeak.
-Lex
I have proposed the SqueakCore ideas about two years ago, at the end of 2004 See http://people.squeakfoundation.org/article/41.html As I proposed six years ago to have more then one mailing list and it finally happen but with a lot of latency. I think we are too late now. Devloping in Python or Ruby si much fast, productive and funny. And the lack of new strong developers (like Avi or Chris Muller) is under your eyes and is very bad.
On 21 Aug 2006 11:04:09 +0200, Lex Spoon lex@cc.gatech.edu wrote:
Milan Zimmermann milan.zimmermann@sympatico.ca writes:
1) "The Board" would start with defining what Squeak is - "Squeak" as a small"SqueakCore" plus "Packages" -[...]
Sounds good to me. I would like to see a body organizing Squeakers more than anything else, and this is the way to do it. I wouldn't put it so strongly, though: in addition to arbitrating the maintenance of the core part, there is a place for helping people exchange their Squeak addons. [...]
-Lex
Milan Zimmermann milan.zimmermann@sympatico.ca writes:
1) "The Board" would start with defining what Squeak is - "Squeak" as asmall "SqueakCore" plus "Packages" - Unfortunately I can only be intuitive here, not saying I know what should be in "SqueakCore", likely it would be much smaller than current Squeak, without Morphic, MVC (UI loadable, is that possible?)
Giovanni Giorgi puso en su mail :
I have proposed the SqueakCore ideas about two years ago, at the end of 2004 See http://people.squeakfoundation.org/article/41.html
This is SqueakKernel.image and Pavel is doing it for a while.
And Spoon is older and backed by Craig mastery.
My SqueakLight is the most tiny working set what have Morphic and could grow and dated of 2003. It's a beginner exercise about dependencies, what the several Squeak "pieces" should like for reach a particular purpose, what was needed for have any code originated in any Squeak could run, etc
I have at this time a working system, what could grow until understand complicated .sar produced by regular 3.9. Not only this, the same .sar could load in 3.9 or SqueakLight, (Rompecabezas, LogicCircus,SqueakRailRoad) is running. And I could have MorphicWrappers, MathMorphs, Monticello and friends (including Monticello 2), Comanche + HttpView + Seaside, IRC.
What is needed is merge all in one killer SqueakCore , but at some time in future this happen.
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
????
I have proposed the SqueakCore ideas about two years ago, at the end of 2004 See http://people.squeakfoundation.org/article/41.html As I proposed six years ago to have more then one mailing list and it finally happen but with a lot of latency. I think we are too late now. Devloping in Python or Ruby si much fast, productive and funny. And the lack of new strong developers (like Avi or Chris Muller) is under your eyes and is very bad.
On 2006 August 21 05:04, Lex Spoon wrote:
Milan Zimmermann milan.zimmermann@sympatico.ca writes:
- "The Board" would start with defining what Squeak is - "Squeak" as a
small "SqueakCore" plus "Packages" - Unfortunately I can only be intuitive here, not saying I know what should be in "SqueakCore", likely it would be much smaller than current Squeak, without Morphic, MVC (UI loadable, is that possible?)
- "The Board" would steer the community to achieve separating the
"SqueakCore", and promote _tools_ that help achieving the separation, and "re-loadability" of some most important packages.
- Once the separation is done, "The Board" would be repsonsible for
steering "SqueakCore" _only_.
Sounds good to me. I would like to see a body organizing Squeakers more than anything else, and this is the way to do it. I wouldn't put it so strongly, though: in addition to arbitrating the maintenance of the core part, there is a place for helping people exchange their Squeak addons.
Yes that makes sense. I felt uneasy commenting on this given I am barely a weekend squeaker, but got encouraged by the original question "what would it take for you[squeak-dev list member] to "buy in" to a central governance model for Squeak".
Also, Squeak would continue to evolve the Squeak we know. Discussions about tossing it and starting from the ground up are interesting but off topic. If you want to do that, then you are free, but Squeak's organization should take care of Squeak.
What I had intuitively in mind (by saying it would make sense to encourage alternative cores) would be their existence would show the API to the core is well-defined and hopefully stable. In a way similar to ability to run (a large set of) packages such as KDE on both Linux and FreeBSD shows there must be well-understood API to the cores (perhaps with different adapters but still defined). Apart from that clarification I agree talking about alternatives was off-topic.
Milan
-Lex
I have little time but I am a Software Architect. So if you (=the community/board directors) like I can draw some guidelines for the SqueakCore project. For instance we can draw together some basic rules for API deprecation, unit testing and so on. Drop me an email :-) My 4 cents (yes I am a bit more rich :)
On 8/26/06, Milan Zimmermann milan.zimmermann@sympatico.ca wrote: [...]
Yes that makes sense. I felt uneasy commenting on this given I am barely a weekend squeaker, but got encouraged by the original question "what would it take for you[squeak-dev list member] to "buy in" to a central governance model for Squeak".
Also, Squeak would continue to evolve the Squeak we know. Discussions about tossing it and starting from the ground up are interesting but off topic. If you want to do that, then you are free, but Squeak's organization should take care of Squeak.
What I had intuitively in mind (by saying it would make sense to encourage alternative cores) would be their existence would show the API to the core is well-defined and hopefully stable. In a way similar to ability to run (a large set of) packages such as KDE on both Linux and FreeBSD shows there must be well-understood API to the cores (perhaps with different adapters but still defined). Apart from that clarification I agree talking about alternatives was off-topic.
Milan
On 2006 August 28 10:50, Giovanni Giorgi wrote:
I have little time but I am a Software Architect. So if you (=the community/board directors) like I can draw some guidelines for the SqueakCore project. For instance we can draw together some basic rules for API deprecation, unit testing and so on.
Hi Giovanni,
Thanks for commenting, and sorry for my late reply, I marked this thread as "todo", but then never looked back until now, with discussions about Strongtalk, I remembered I left something on my "todo/reply" that is related.
I do not have much to add, while I continue liking the idea of defining modularity and well-defined interfaces (and possible interchangeability) between VM[Current, Pepsi, Strongtalk]<-->Core[Current, Spoon]<-->Packages, (which themselves would be loadable/unloadable starting with the "lowest level" such that Tweak/Morphic/NativeUI), I am simply not qualified enough to drive such SqueakCore effort, or have enough time to help significantly. Having said that, if someone, or the board, goes this direction, and such modularization effort is established, I will try to participate and help to the best I can (which may amount to well below 1 cent :) )
Milan
Drop me an email :-) My 4 cents (yes I am a bit more rich :)
On 8/26/06, Milan Zimmermann milan.zimmermann@sympatico.ca wrote: [...]
Yes that makes sense. I felt uneasy commenting on this given I am barely a weekend squeaker, but got encouraged by the original question "what would it take for you[squeak-dev list member] to "buy in" to a central governance model for Squeak".
Also, Squeak would continue to evolve the Squeak we know. Discussions about tossing it and starting from the ground up are interesting but off topic. If you want to do that, then you are free, but Squeak's organization should take care of Squeak.
What I had intuitively in mind (by saying it would make sense to encourage alternative cores) would be their existence would show the API to the core is well-defined and hopefully stable. In a way similar to ability to run (a large set of) packages such as KDE on both Linux and FreeBSD shows there must be well-understood API to the cores (perhaps with different adapters but still defined). Apart from that clarification I agree talking about alternatives was off-topic.
Milan
squeak-dev@lists.squeakfoundation.org
-
Cees De Groot -
Giovanni Giorgi -
Lex Spoon -
Lic. Edgar J. De Cleene -
Milan Zimmermann -
Peter Crowther -
stéphane ducasse