[IAEP] squeak/etoys accepted as free software... (was Re: Sugar on Ubuntu - Summary

[Jonas Smedegaard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Nov 07, 2008 at 02:56:44PM -0800, Alan Kay wrote:
>Sure, I completely agree. And now is a chance to apply the idea that 
>via the Internet "the whole world" is the pool of resources for making 
>and taking care of open and free software.

In a sense I believe that is happening already today:

When end-users experience one system (or distribution) as unreliable and 
switch t another, they implicitly "vote" for that oyher system, and 
"advertise" it through their social network.


>Seems as though no simple group can handle the scaling implied by 
>having the whole world supply software, even if only one approach is 
>used.

And currently several groups work together: Upstream authors of software 
do their own balancing beteen quality checks and adding new features. 
Distributors may have different balancing, or might sometimes patch in 
features not yet (and maybe never) accepted by the original authors.

End-users are free to grab directly from upstream or use any of the many 
distributors.

When Debian, arguably the largest and most flexible FLOSS software 
distributor, decides to not distribute Squeak, it is not a signal that 
Squeak is bad or inferior. It is a signal that Squeak and Debian do not 
fit together. Either we leave it at that (Debian and MS Excel also do 
not fit together), or we adjust one or both of them if we see enough 
benefit for them fitting together.

Just because Debian is large does not mean the whole FLOSS community 
ought to obey whatever Debian decides as their playground (including 
DFSG). It is opposite: Debian is big _because_ a lot of software happens 
to fit (or can be convinced to adjust to fit) the DSFG, and a lot of 
volunteers find it interesting to do the work. Work that at least in the 
past was often duplication of work already done for Redhat.


Seems to me it scales well. :-)


>As Jecel pointed out, it is highly unlikely that any distribution group 
>is really looking at any appreciable fraction of the lines of code they 
>are distributing, nor could any such group really handle most bugs 
>(whether dealing with security issues or not). This is in part because 
>most software systems have real problems even being written and 
>debugged (even understood) by their inventors and programmers. 
>Distributors of such software are going to have even more problems 
>understanding and fixing, if they try.

Distributors are sometimes able to spot flaws missed upstream, because 
they are looking from a different angle: Instead of actually 
understanding in detail each code piece, they do pattern recognition.

In 20.000+ software packages built on 10+ hardware architectures, some 
patterns emerge about classic typos or misconceptions - about the 
hardware, about the location of libraries, about use cases, about 
tmpfile handling, whatever. Many upstream developers deal with each of 
these issues once, and might not be the most clever guys at all parts of 
their own code. Distributors can help pass on knowledge between 
upstreams, through pattern recognition.

Personally, I experienced this recently while initially packaging a 
large Perl-based project, and also engaging with upstream in design 
decisions (like how to split code into modules, when to do a release, 
and stuff like that). I consider myself a lousy programmer - I can 
stitch together code made by others, but can only very slowly and 
clumsily write code on my own from scratch. Still we found that my 
insight from packaging 50+ packages for Debian already, some of them 
Perl-based, some of them completely different, that my ability to 
recognize patterns in the code - in the directory tree structure, in the 
versioning, the naming, the documentation style, the communication 
style, and a bunch of other stuff - was valuable for the project and 
noticable helped improve it. I even discovered a few bugs (to my own 
surprise). :-)


>Part of the honest worry about these issues comes from very good 
>reasons not to just trust everyone. But it also seems that e.g. Debian 
>needs to widen its circle of trust to include experts in wider 
>varieties of programming. There are plenty of trustworthy Smalltalkers 
>and Squeakers, and there is absolutely no reason that some should not 
>be on call to deal with perceived problems.

Depending on interpretation, I think we all agree on that. Including the 
Debian ftpmasters.

Debian in reality trusts all upstreams. And ideally discuss any changes, 
including security fixes, with upstream authors.

At the same time, Debian in theory trusts no upstreams: Each Debian 
package maintainer is expected to understand the maintained package(s) 
well enough to ensure that the code is reliable. Yes, it is often an 
impossible task. But still a sane goal, as long as not blindly assumed 
working in reality.

If you mean that Debian ought to trust upstream to fix bugs and take 
care of security issues _instead_ of its own package maintainers, then I 
disagree: I believe *both* upstream and the distribution-specific 
routines should be applied in parallel.

Some bugs and flaws can even be caused by the context of the 
distribution, so impossible for upstream to spot. An obvious example is 
a makefile generating a private key for strong encryption, and the 
packaging routines then distributing same pre-compiled private key to 
all systems worldwide. In theory upstream authors should have 
distinguished the "configure", "build" and "install" phases, but reality 
is much more complex. There are many more ways than even using 
makefiles. As you would know - snapshotting your live "world" and 
distributing that as "source"... :-)


>Very best wishes,

And same to you. Nice discussion!


  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkU3jEACgkQn7DbMsAkQLjnngCeOPFI+qHq/tKe2skMPWSVn+aF
Q34An0IIx7eJFFBJ5ZMj0FsGv1vwJlzW
=FfXo
-----END PGP SIGNATURE-----