Welcome to the mailing list for the Scheme.org domain name.

First, some fundamentals. The registrant on file for Scheme.org is
Magnus Ahltorp from Sweden. The administrative and technical contact
is Arthur Gleckler (known to Schemers as the current SRFI editor). The
previous admin and tech contact was Shriram Krishnamurthi (known for
running Schemers.org among many other contributions). Shriram was
happy to hand over Scheme.org to people who have time to develop to
it, and would like to phase out Schemers.org in favor of Scheme.org
once the latter has been properly established. Magnus is also happy to
be hands-off but would like to retain ownership of the domain to
ensure that it stays non-commercial and does not track the behavior of
visitors. Magnus has kindly pre-paid the domain until 2029. The domain
registrar and DNS provider is Gandi.net.

On to the plans: The essay below is an attempt to lay out a particular
vision for Scheme.org. It has been hashed out by me and Arthur with
input from a handful of other Schemers. It advocates for an unusual
approach because Scheme is governed differently from most programming
languages. It is long and detailed; please bear with it, think about
it for a while, and tell us what you think on this list so we can get
a conversation started. Going forward, we want the administration of
Scheme.org to happen entirely in public so that everyone is clear on
where things stand with this important domain.

The title of this essay is chosen to make a particular point.

As programmers, we are used to fast-moving projects, changing plans
and informal customs. Getting software written at all is so hard that
we have little patience for elaborate social protocol.

We believe Scheme.org should be viewed as a fundamentally different
kind of project: a conservative one that prioritizes preservation and
planning even when that makes new development more difficult.

Scheme is not a new language. It comes with almost half a century of
history. It has a well established reputation, now guarded by us.

Scheme's continuity rests on a loosely organized network of volunteers
who come and go. While this is wonderful, the risk of key people going
out of reach is ever with us. We must take care not to jeopardize the
continued availability, maintenance and development of our resources.

Schemers are known to prize independent thought, sometimes to a fault.
Our most notable disagreement was the R6RS vs R7RS split. We should
take care to preserve neutral ground at the center of Scheme so that
adherents of different sub-communities can continue to work together
on shared interests even during times when there is widespread
disagreement over the future direction of Scheme. Likewise, we should
take care that no particular sub-community can alter the public image
of Scheme to the detriment of others.

Finally, we should protect the Scheme community from being co-opted by
commercial, academic or political interests for their own purposes.

All of the above concerns are fundamentally tied to the name itself:
Scheme. Whoever owns the name holds significant power over the public
image of the language and the ability of people to organize around it.
That is fine for languages headed by a definite person or group, but
Scheme has no owner. The closest thing we have is the Scheme Steering
Committee. They ratify the RnRS reports but are far too busy to tend
to the day-to-day matters of the language and its community. Running
the language community thus falls on its most avid users. That is us.

As the internet domain most obviously linked to Scheme's name,
Scheme.org is the one entity best placed to represent Scheme in the
world. With Scheme.org now in friendly hands, we should take this
opportunity to gather around it, make it the best we can, and do our
best to ensure it carries on to the next generation of Schemers.

Why think about the next 20 years? A lot can happen in a couple of
decades, and it's not guaranteed that any of us will still be involved
with Scheme after so much time. Setting our sights that far into the
future forces us to design a social and technical structure to outlast
ourselves. We can start with a template and gradually refine it. If we
do this right, the rate of change will slow down over time and the
community will increasingly trust in the stability of the structure.

Since humans are bad at predicting the future, the most likely success
formula is extreme simplicity in the core processes:

- We cannot have any rules that are hard to interpret since we may not
   be around in the future to give advice about them. Rules, procedures
   and responsibilities need to be simple and straightforward.

- We have to codify all knowledge in either code or written documents.
   We can't rely on word-of-mouth and knowing people who know things.

- We have to take maintainer fatigue into account. Scheme.org needs to
   have an administrator at all times, and it's a lot easier to get
   someone to commit to a job when it's easy and doesn't take much
   time. We can't have routine procedures that take a lot of effort.
   Likewise, training a new administrator has to be quick and easy.

- Scheme.org is predicated on the idea that Scheme, the DNS (Domain
   Name System) and the WWW will still be around 20 years from now.
   However, it's difficult to say what other tools will be popular. We
   should favor simple, well-known and platform-neutral tools without
   elaborate dependencies.

Moving further away from the core of Scheme.org, the stakes are lower
and we can be more relaxed. But as with the Scheme language itself, we
should put a great deal of thought and care into a core that will
stand the test of time.

On the technology front, we believe one trick in particular holds the
key to success: subdomains. The internet is naturally divided by DNS
delegation. This exactly mirrors a desirable governing structure for
Scheme.org: The root Scheme.org and its web front page should be
simple, conservative, and closely guarded -- like a constitution. Less
critical subdomains can afford to be more free-wheeling and
experimental about both their technical and social aspects.

Subdomains are simple to add and cost no extra money. They are a
convenient unit of division to work with in various networking,
security, and sysadmin contexts. We can freely make lots of them:

* r5rs.scheme.org
* r6rs.scheme.org
* r7rs.scheme.org
* srfi.scheme.org (should move late -- will be a big ordeal)
* docs.scheme.org
* pkgs.scheme.org
* lists.scheme.org
* files.scheme.org
* registry.scheme.org
* fantastic.scheme.org (your adventurous Scheme implementation here)
* ...

It's important to note that we could have as many as 50 subdomains and
the site would still be navigable. The front page can group them into
categories, with a short explanation next to each subdomain.

There would naturally be two kinds of subdomains:

* Those owned by a particular group based around a given standard,
   implementation, or tool. Each subdomain of this kind should be
   controlled by the group in question.

* Those that are community-owned resources about a particular topic,
   similar to the new Scheme Topics mailing lists at srfi.schemers.org
   and our many GitHub organizations. They should operate by consensus,
   with decision making on a public forum such as a mailing list, and
   with the top level Scheme.org administrators acting as last-resort
   tie breakers for any disputes.

Each subdomain should be responsible for setting up and maintaining
its own servers. The top level Scheme.org administration should only
be tasked with updating DNS records as requested, and with maintenance
of the Scheme.org front page. Delegating all other responsibilities to
subdomain admins will naturally ensure the fault tolerance of
Scheme.org as a whole and enable a light workload for the people
committed to be the top level administrators.

One important angle missing from the above treatment is the legal one.
No amount of goodwill or technical savvy can help us if we are no
longer the registered owner of Scheme.org. Scheme is a common English
word, and Scheme.org could be sold for upwards of 10k USD if someone
was either greedy or desperate for money. It could also be taken over
by an organization incompatible with our goals.

To that end, a few of us have pondered whether it might be a good idea
to set up a formal non-profit association to act as the legal owner of
Scheme.org and any other important internet properties related to
Scheme that people wish to donate to it. We may not have anyone in the
Scheme community who is excited about the paperwork involved, but the
stakes are high enough that if the cost is not prohibitive this step
is worth taking anyway.

Ideally Scheme.org would become so reliable that Scheme implementors
could feel as comfortable hosting their implementation's primary
website at fantastic.scheme.org as they would at their own separate
domain fantastic-scheme.org. There would be nothing like gathering
implementations under the umbrella of Scheme.org to signal the
cohesion and organization of the Scheme community to outsiders -- a
level of cohesion that is probably unmatched by any other significant
language. But authors hold their implementations dear, and major ones
will not take such a drastic step without a deep trust in the social
and legal basis of Scheme.org. If we work hard at building that trust
for a number of years, this may eventually be our ultimate prize. But
even without such an accomplishment, every extra resource we add under
Scheme.org builds the reputation of Scheme as a collaborative
community and provides direct benefit to users who can thus more
easily find their way around Scheme.

If you're interested in helping us bring Scheme.org and its subdomains
to life, please join this discussion. We're looking for volunteers to
create and maintain Scheme.org and interesting and useful subdomains,
and to help us figure out the process for organizing this effort for
the long haul.