[Spaceapi-devel] SpaceAPI forked at spacedirectory.org - what's the plan?

[Roland Hieber]

For the record, I'm a member of the spaceapi GitHub organization, but
I've never been much of an active developer, neither do I know how
everything works, how to deploy anything or have access to any servers.
So I'm not really the one to decide here. (However, I'm not disinclined
to play a more active role in the future.)

I'm absolutely pro rejuvenation of the project with a higher bus factor
and easy deployment. If that happens under the old name or a new name
mostly depends on whether the domain owner of spaceapi.net (probably
Romain? whois is not helpful) is willing to join forces. After all,
Romain has done a bunch of work over the years to keep the SpaceAPI
running, so it should also be his decision whether to hand the name over
to a new team (maybe with a few of the old people?). And after all, it's
not like we could force him anyhow ;-)

Rejuvenating the directory under the old name (and domain) certainly has
the advantage that already existing applications can use the old
directory URL without any updates. Also, you don't have to teach people
a new name for the same stuff.

On 21.01.2017 22:33, Danilo Bargen wrote:
> We also discussed decentralization a bit - as long as the directory
> consists of simple JSON files it can be hosted by anyone. Maybe adding
> an automatic git sync script might help to get more "mirrors".

To prevent single-point-of-failures, the most reliable way that comes to
mind would be some kind of DNS pool for the mirrors, e.g. have some
canonical name like pool.spaceapi.net / pool.spacedirectory.org with
multiple A/AAAA records pointing to the respective mirror servers. HTTP
mirroring is a solved problem, we don't need to worry about that.
Ideally, the canonical directory server signs its directory so that the
mirrors can verify what they are mirroring. Okay, many ideas here, but
let's cross that bridge when we come to it :)

> Regarding the code and directory, having everything in a single Github
> organization with multiple active members would be good to increase the
> bus factory.

Not neccessarily. The bus factor not only depends on having people in
the organization with merge access, but also on knowledge how to set up
things, how to maintain things, and server access for when things go
wrong. My rule of thumb [0] is: at least two people for everything.

[0]:
https://wiki.hackerspaces.org/The_Responsibility_Pattern#Sub-Pattern:_Distributed_Responsibility

> Doing discussions on Github probably wouldn't be too bad
> either. In our case we added a "meta"-Repository:
> https://github.com/spacedirectory/meta Not a lot of discussion so far
> though.

Hmm. We have this spaceapi-devel mailing list which already exists, and
I've never really used GitHub for discussions, but they have good e-mail
support for issues, so both seems okay to me.

 - Roland