One conversation Jim Groom and I had last month in Australia was about development in the Domain of One’s Own (DoOO) space and how to best facilitate growth. This post is not the answer, but our discussion continues to spur thoughts that I want to document. In boils down to this:
I want a Server of One’s Own (SoOO), not unlike a Domain of One’s Own.
What I imagine is a space where I can pursue further tinkering than what DoOO affords. For example, I really want to setup and play with more WebApps than are present in Installatron. I’d love to install and test UnHangouts (code here)—put it through it’s paces to see where it might be useful on campus or in a classroom. (I’d also love to setup up the Twine WebApp to explore!) This dream is currently hindered by lacking a test space for such tools (and the time to spin-up/learn such DIY tools).
Not that it’s a guarantee, but having more development options available (and theoretically more people tinkering) via SoOO has the potential to help us move beyond DoOO’s signifiant dependency on WordPress as Martha Burtis cautions. I agree, I don’t want our imaginations to start and stop with the WebApps that are currently offered in DoOO’s Installatron. I want more.
So, in practice what does all this mean?
In my mind, a Server of One’s Own would lower the barriers that hinder me pursuing more DIY learning/creating. In other words, I’d like a development environment that’s affordable, powerful enough, already configured, and is primed for exploration. (Also separate from a DoOO server that hosts other peoples personal data but potentially still connected so SoOO could be used in tandem with domains preset in DoOO.) A server that I don’t have to setup and configure every time I want to do some development.
One part of this vision is transforming terminal commands into a visual interface, much like Installatron does for loading WebApps into DoOO. Going back to the UnHangouts example, being able to install dependencies (node.js express, sockjs, redis, etc.) on a server with the click of a button in preparation to load GitHub code would be spectacular. If this was setup via Vagrant, Salt, or Yarn (or however) to let me have server dependencies up and running easily, that would be spectacular.
I recognize in practice this is not straightforward to pull off and many questions remain:
- How much do you control the development environment?
- How standardized vs. personalized can a server be in SoOO?
- For the one-click buttons that are part of the visual interface in SoOO, how are these install scripts handled?
- Etc.
- Etc.
- Etc.
Still, I’ve run into this desire for SoOO in the past. When playing with Sandstorm, exploring tools like Ghost and self hosted GitLab—I’ve wanted to have a space where I could more readily play.
Don’t get me wrong, I’m not afraid to tinker and I believe we shouldn’t always skip over the valuable learning experiences to be had in server side web development (many of which I still need to explore myself). But for folks like me who are self taught (and blog taught) server admins, SoOO would be a dream come true as a learning tool.
The featured image is provided CC0 by Thomas Kvistholt via Unsplash.
Comments