Magma and Magma on Pharo questions

[Keith Hodges]

Keith Hodges wrote:
> Chris Muller wrote:
>   
>>> To make it work with Seaside is a problem that I have not yet sorted out.  seasideHelper requires installing the package
>>>     
>>>       
>> Hi Ramiro, I continue to be confused by statements like this..
>>
>> I am still unclear about what Magma needs to "work" with Seaside.  Our
>> company is using Magma with Seaside just fine, no special
>>   
>>     
> That's a shame, a lot of work went into them, and you guys would be far
> better at making sure it all works than I am.
>   
And if you wonder why I am reacting this way...

I make generic contributions because I NEED other people to join in and
help refine them so that they will apply to more specific scenarios. My
thinking is that if you make a contribution to the OSS community then
that community will value that contribution and will join in with
additional skills to make things better for everyone.

For my contributions to be worthwhile, I need other people to join in.
The fact that the default position chosen by most significant
squeak/pharo activists is to not join in, makes my contributions a waste
of time. Generic ideas need buy-in otherwise they can do nothing other
than fail. I might as well just make my own specific code for my
specific use case, and it would take 10 times less effort, and I would
get paid 10 times as much for doing it.

As an example, I extended SUnit so that you can have a single test
package that will run in all squeak images. You can mark individual
tests as working in squeak 3.9 but not in 3.8 or in pharo but not in
squeak. Did I need to do this? No, because I only use one image at a
time. So the only way it becomes useful is if someone who has a package
that they want to test in multiple use cases, actually uses it. It might
be useful for Rio or Magma for example, but the real use case is when we
wish to share one set of master tests between kernel packages.  However
it turns out that when it comes down to it everyone will roll their own
conditional support. The Pharo guys refuse to use it, because its not
pharo specific etc etc.

I invested months on MC because I naively thought that it needed fixing.
It needed fixing because if you want to use someone else's package and
have to use a method override, and at the same time you want to try and
contribute code back to the package that you are using so that you don't
need to use a method override in the longer term, then you need
method-overrides to work. However I have discovered that such
contributions back to seaside/pier and a number of other packages are
generally ignored, even if you submit them 3 times, so really I didn't
need to contribute fixes back to them in the first place, and really I
didn't need to fix MC since no one else appears to care that it is broken.

So after 3 years of having the attitude of "contribute as much as you
can" because the community will contribute back eventually from their
skills because we all recognise that we cant do it all, was I now see
rather misguided, but you cant say I haven't tried. This is the trouble
with smalltalk, its too easy for everyone to do their own thing, and so
everyone does, there is no incentive for people to really collaborate
properly... as in teams of more than one.

I am not a team of one, I never have been, and I cant function as one...
our "community" doesnt appear to have the ability to to work
collaboratively, heck most of the code out there is undocumented by
default, doesnt that say something, and now we have our next release
being hacked on by a group of individuals, not a team. I just think that
the whole deal is on a hiding to nowhere.

Keith