Scheme.org: Protecting Scheme's name for the next 20 years
Lassi Kortela
(22 Nov 2020 21:54 UTC)
|
Re: Scheme.org: Protecting Scheme's name for the next 20 years Amirouche Boubekki (24 Nov 2020 16:37 UTC)
|
Re: Scheme.org: Protecting Scheme's name for the next 20 years
Lassi Kortela
(24 Nov 2020 11:37 UTC)
|
Re: Scheme.org: Protecting Scheme's name for the next 20 years
Marc Nieper-Wißkirchen
(01 Dec 2020 18:39 UTC)
|
Who owns Scheme?
Lassi Kortela
(01 Dec 2020 17:33 UTC)
|
Re: Who owns Scheme?
John Cowan
(26 Dec 2020 05:49 UTC)
|
Re: Scheme.org: Protecting Scheme's name for the next 20 years
Arthur A. Gleckler
(01 Dec 2020 18:45 UTC)
|
Re: Scheme.org: Protecting Scheme's name for the next 20 years
Amirouche Boubekki
(24 Dec 2020 16:59 UTC)
|
Re: Scheme.org: Protecting Scheme's name for the next 20 years
Lassi Kortela
(27 Dec 2020 14:02 UTC)
|
Hello, That is a great idea! Thanks for working on this. Will the scheme.org domain work like https://js.org/ ? Le dim. 22 nov. 2020 à 22:54, Lassi Kortela <xxxxxx@lassi.io> a écrit : > > 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. -- Amirouche ~ https://hyper.dev