[IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar

[Michael Stone]

Dear Sugar folks,

I have avoided wading into this discussion for some time because I wanted to
see where it went without my interference. Therefore, before I say anything
else, thanks for the entertaining show. :)

Next, here are some thoughts for you, based on my own work, uses of Sugar, and
past conversations with other principals.

Regards,

Michael

--------------------------------------------------------------------------------

Dan wrote:

> It will affect packaging and distribution. My suggested model (as
> employed all over the open source world) is that the developers would
> release source distributions and let distributions do the packaging
> and distribution.

My suggested model, employed all over the real open source world, is that
people write web pages (the most popular kind of open source software!),
publish them at URLs, and feed those URLs to interpreters. 

Only people with unusual quality or distribution requirements "release" or
"package" their web pages. Most people just write them and fix problems that
people yell about.

Consequently, I want to make using activities more like web pages. That's why I
work on rainbow and on networking design.

NB: ZeroInstall, which was mentioned earlier in this thread by Ben, sure seems
to me like it comes from the kind of world that I want to live in, even if
Bernie isn't so sure because the "page" he tried to visit contained an broken
link. Remember, the web used to be that way too!

> Even though a Sugar system with distro-installed packages is crippled
> (activities cannot be erased or updated through any realistic means),

Then we should not rely on distros for dealing with activities. (They're
absolutely a great thing to build Sugar Platforms out of; they're just not so
useful for this other crazy thing we want to do. This is fine. Browsers are
also an absolutely great thing which is not right tool, today, for the
activities problem.)

>> But we also have activity authors that don't want to go through the
>> hassle of learning git :/
>
> This is getting completely ridiculous. So how do they manage the
> versions and releases of their packages?

They don't. In my opinion, ideally, they click a URL and the software they
clicked runs most of the time. They don't care what version is underneath. If
they want to change it, they hit view source and edit. If they want to share
it, they share the URL, however they like.

If they want to merge their changes with those of other people or if they want
their software to run on the computers of people with wildly different setups,
then, eventually, they learn more about the art of building portable software.

The point is that none of version control, packaging, releases, and so on are
necessary for having fun writing software or for learning; they're just useful
for engineering.

> Do these get put on a.sl.o?

Probably not. Many of the people doing the work won't even have internet
access, though they will have local networks. Take Peru as a simple example.

> If so how do we verify the source code and whether it can be
> distributed?

We don't and we can't. But other people can and will anyway.

> How do we verify any binary content they might include?

We don't and we can't. But people will happily use it anyway.

> What they do privately is their own business but if it appears on
> a.sl.o it needs to be verify able and trackable. 

Sure. Ben's point is that supporting this "personal hacking" is A PRIMARY USE
CASE. If we're not doing it, we should give up and go home.

However, take heart: there is a DIFFERENT primary use case; namely, supporting
distro-based engineering efforts useful to deployments, which is quite amenable
to the sort of solution you're comfortable with.

I believe that these are compatible points of view as soon as we admit that
different mechanisms are needed for the differing use cases. What's the problem
here?

> There needs to be a minimum set of requirements.

Your set of "minimum requirements" is a good set of requirements for
engineering a great distro like Fedora, but that's not the only thing we're
doing here. In particular, your "minimum requirements" violates Sugar's design
goal of "low floor, high ceiling." Them's the breaks.

>> And even worse, we want people who are not yet able to create
>> activities from scratch to do simple modifications to existing
>> activities and redistribute them.
>
> That's fine. Its open source and it then becomes their problem but it
> shouldn't be a central issue what they want to do with modified
> activities. 

It's a central issue because, as Ben explained, supporting it is a fundamental
principle of our work. Consequently, we're allowed to solve other parts of our
problem in different ways, but not in ways that are incompatible with it.

> The activities hosted on a.sl.o should meet a minimum
> requirement. Otherwise we get into a situation where there's no
> guarantee of the Activity whether that been the source or the
> stability of it.

Please read Stuart Cheshire's "law of networkdynamics":

   http://www.stuartcheshire.org/rants/Networkdynamics.html

It explains better than I ever can why we don't want such a guarantee in the
world at large. *Perhaps*, a.sl.o is the right place for that guarantee to
exist in the small. Maybe a subsection of a.sl.o would be better, just like
Ubuntu divides things up into "components":

   http://www.ubuntu.com/community/ubuntustory/components

--------------------------------------------------------------------------------

Lastly, about the idea of shipping everything in Python, or Java, or Smalltalk: 

Give up -- this works for mobile phones, not for "things to think with"! 

Programming languages are prime examples of "things to think with". We're
trying to provide people with lots of these, and with the best ones that we can
find, remember?