Reliability

There are many services that exist within devhack. these services are provided with NO WARRANTY, and are provided on a best-effort basis.

now, services may find themselves thrust into a higher level of expectation of stability than "none", either through explicit promises by folks maintaining those services, or through natural dynamics of use and dependency on useful services. /dev/hack is an inherently unstable place, the amount of reliability that can promised with regards to security of belongings and data within the space, utilities provided by the space, and other foundational things are also provided on a best-effort basis by volunteers, and may not always be available when desired.

That being said, here's an exhaustive list of interfaces that /dev/hack2 the nonprofit tries to, on a BEST EFFORT basis, try to keep operational:

• a way to get into the space, a way to restrict who can get into the space.
  • currently provided by cardkey and gatekeeper
• a way for members to contact eachother
  • de-facto provided by matrix, but can also be facilitated by various communications platforms like telegram, signal, email, irc, etc
• a way to turn on the lights at the space
  • de-facto provided by dumb lightswitches & homeassistant
• a way to give money to the space
  • de-facto provided by member services but can be done by anyone with stripe admin access
• basic utilities, such as: water, electricity, trash services, heating, and cooling. And an environment where unsupervised projects can rely on those utilities
  • provided by gelb building, foreign relations hat, & other devhack volunteers & leadership
• A way to connect to the internet from commonly used devices such as laptops. And an environment where unsupervised projects can rely on those utilities
  • provided by wifi, but usb-c capable ethernet could also satisfy this.

these interfaces are left intentionally vague. prescribing the technology behind how these things happen is not an easy thing to do, and folks frequently end up using "unofficial" devhack services as their primary implementation of these provided interfaces. And members are invited to create more.

The items on this list does not mean you shouldn't feel invited to contribute and improve them, it just means you need to be careful about them and maybe ask someone/someones just in case.

"you should feel bad about breaking these things"

this list was primarily created with the question "will the functions of devhack stop if these things stop being allowed" involved.

ideally, the devhack-provided implementations aren't the primary way things are used. hacking onto the space is one of our core tenets, and making it harder to do that is sad. And promising easy-to-use/desirable-to-use reliable services is a difficult thing to do.

we don't want this list to grow too much, reliability increases costs and decreases hackability.

additionally, members are invited to document their own services' levels of reliability. Reliable servers are nice to depend on, but become inherently harder to learn with, hack onto, and fuck around with.

Members who want to create systems that, both:

1. do not enable others' to create things using those systems, or
2. do not allow others' to poke, prod, and hack at the system itself, for fear of lowering reliability/availability/stability

are invited to consider doing so elsewhere, as a project that is impossible to collaborate with is not a good fit to the space.

Having stable systems is nice! Reliable systems enable for folks to build more hacky things on top of them, while the foundation that they're building on can be abstracted away / not worried about.

Say you've created something that has become useful and beloved to many folks, but there is more instability & downtime than people want, like, or expect. Here are some things you can do to try to re-adjust expectations:

1. Have more documentation/propaganda about the warranty/reliability/stability of the service, especially in prominent places.
2. Make your system more unavailable. On regular or irregular intervals, create downtime to enforce the expectations that your system is unreliable.

now, these things come at an obvious cost: people like reliable systems. The more unreliable your system is, the less people will depend on it to use it. They might fork it & maintain their own instance of it that tries to maintain a higher uptime than you want for yours. And this is a good thing!