Menu

Calypso, Sandstorm, and Cyberinfrastructure

This week, WordPress announced a new WordPress.com and desktop-based version of WordPress, codenamed Calypso, which allows you to locally manage multiple self-hosted and WordPress.com hosted websites. Essentially, it brings the streamlined WordPress.com interface to all. In fact, this is my first post written entirely on Calypso.

Mike Caulfield wrote an excellent post yesterday titled Calypso is the Future of Personal Cyberinfrastructure and, while don’t think that Calypso is the exact, specific answer (or believe that was necessarily his point), he brings up several points that I do completely agree with and wanted to take time to address.

To sum up Caulfield’s thoughts that he has articulated both yesterday as well as 18 months ago, there is too large of a barrier to entry to owning your own data.

If I want to own my data, I have to run the admin interface and presentation layer on my own server. This means dealing with updates, hackers, spam, denial of service attacks, etc. It sucks, and only a sliver of the population will ever do it, no matter how nice you make cPanel.

His answer is that there needs to be a service in which you can still own your own data but you can also pay for services that streamline the taxing nature of server administration, which he has termed “Storage-Neutral Apps.”

So let’s talk about what Calypso is and what’s intriguing about it and how at OU we’ve sort of been using it since this summer.

My CTE colleage, Keegan Long-Wheeler, is a mobile enthusiast and is constantly thinking deeply about what mobile learning looks like in the classroom. Us techies who like our command line driven desktops tend to poo-poo tablet-only users but it becomes increasingly hard to ignore it’s presence when Walmart has 20+ tablets on sale for under $50 for Black Friday. I don’t think I’m going out on a limb when I say that tablets are an incredible gateway to connectivity and should not be ignored.

Last May, we had been comfortably running OU Create for about nine months when Keegan came up with a Faculty Learning Community idea called Mobile Blogging and Scholarship. Faculty who joined would be given an iPad and would spend time working through curriculum based around digital workflow, scholarship, engagement, and collaboration. Faculty would also be blogging their experience along the way. Side note: Keegan has built out the entire curriculum as well as public aggregation of the faculty blogs. Check it out.

As I was helping Keegan think through the structure for the Faculty Learning Community, we kept getting hung up on how much effort would go into setting up their site via OU Create. Do we have to spend one out of six meetings just getting setup? To get a group of around 10 faculty usually takes Keegan and I roughly an hour and half, meaning it would be a full session. Login. Pick a domain name. Introduce CPanel. Install WordPress. Create new login credentials. Explain how these are different and disconnected from your OU Create login. THEN setup up the iPad app to run self-hosted WordPress site with said credentials. For this specific faculty learning community focused around tablet app-based tools (WordPress, Canva, YouTube), owning your own space wasn’t an objective, and thus this process felt taxing at best.

So I made a suggestion for Keegan. Let’s nix OU Create for just this once and have them simply sign up for wordpress.com. In the event someone wants a full domain, we’ll be glad to show them how to migrate to OU Create so they can have the opportunity to setup multiple WordPress sites. But, for this purpose, the subject is blogging, not sites or portfolios or online presence anyhow.

And if you’ve played with the WordPress iPad app, Calypso will feel very familiar. In fact, minus a little bit more control over themes, it’s nearly identical to the end user.

So what’s the big deal with Calypso? I would say it lies more in what WordPress is saying about where they are headed rather than the product itself since we’ve had some form of Calypso for awhile. In some respects, it’s a compromise. First, it’s javascript based. I’m going to get a little bit technical so apologies. The recent history of web coders goes something like this: Everybody used to really get along. PHP worked well on servers and JS played well with the browser. The two needed each other. Until some smart kid comes around and figures out you can use JS on the server side (Node.js) and all the sudden you don’t need PHP to build server stacks. Thus, the Montagues begin to fight with the Capulets and the war between each other continues to happen to this day.

To some degree it’s like the old Microsoft versus Apple computers. It can be argued that one is newer and hipper, but it can also be argued that one is the stable workhorse. Nevertheless, folks are predicting that more and more web developers will continue to move over to the Node.js framework.

So here’s my theory. Ok, so let’s assume PHP is on its way out and you’re WordPress. Do you get rid of PHP and go with JS? Of course not. Why? Well, your application powers 25% of the web and it’s mostly running on LAMP based servers (The P stands for PHP). While it’s not impossible to running something like Node.js on a LAMP server stack, it’s certainly neither easy nor out-of-the-box to most folks on shared hosting. And WordPress is about ease of use as much as anything else.

So the next best thing you can do is compromise and build a JS based app that can run as an extension of the PHP server side application. Enter Calypso. See that wasn’t so hard to explain was it?

One of the main benefits of Node.js is speed, and I can attest that Calypso runs faster on the Desktop than WordPress.com (this should be no surprise though considering there is no brower). A second major benefit is JSON. Calypso communicates with WordPress entirely through REST API. Calypso has also been open sourced. Meaning, theorhetically, developers could write multiple desktop applications for managing multiple WordPress sites in the similar fashion that several folks have built apps like HootSuite and TweetDeck to manage Twitter locally through Twitter’s API.

So here’s where I might agree with the premise but not the assumption that Calypso is the answer to everything. Obviously, Calypso is for one application which can run on your server (WordPress). What I would rather see than a bunch of Calypsos is a better workflow to application installation. If we want folks to assume authority of their data, I agree with Caulfield that we have to push towards making it easier to do so.

At OpenEd, Grant Potter gave me an invite to Sandstorm.io, which is a new open source platform for servers that recently raised $50k+ via IndieGoGo. What I love about Sandstorm is that it throws out this whole PHP vs JS business and says “install whatever you want” but also takes a similar one-click install approach to applications, much like Installatron. This means in the same way I can easy install applications on my iPhone, I can install WordPress, Ghost, Mediawiki, Rocket Chat (an open source Slack-like tool) Wekan (an open source clone of Trell0), etc. and the applications language need not matter. Finally! An easy approach to accessing modern web apps. Sandstorm, similar to Docker, is focused on getting as many applications available to the end user, but is laser-focused on making it process of install applications easy to everyone:

With Sandstorm, the person deciding what software to deploy is not necessarily a developer or system administrator.

Source

Here’s a video I put together to show how quickly you can install these applications:

Sandstorm.io is still in Beta, but as Jim Groom told me, it doesn’t play very easily with domain mapping, so they would have to solve that issue. But the approach is unbelievabley smart. My criticism of open-source has been that, while we may have thousands of different tools to play with, most with the newest fastest slickest approach to design, no one has done the best job with making enough of them accessible to those who have no desire to use a command line interface.

Before going for breadth of apps, which can be overwhelming in something like Installatron or Docker, let’s make it really easy for the user to access these apps first.

 

Featured Image: A flickr photo shared by Kitty Terwolbeck under a Creative Commons ( BY ) license

  • jimgroom
    Adam,

    I love your thoughts on this, and we’ve been looking at Sandstorm for a while, and the stuff Open BC is doing with it is pretty awesome. One of the things we have been trying to wrap our head around for a year is how we can scale that for an institution like we are the LAMP environment. What I mean with domain mapping, is right now you would need to get a wildcard subdomain from them off sandcats.io (https://docs.sandstorm.io/en/latest/administering/wildcard/), which would make it difficult to roll it within a CPanel infrastructure for us, not to mention provisioning. That said, we are figuring out how we might provide access to oasis (their managed hosting service) through Reclaim, it would be sick.

    The other thing we have been looking at is Kuberdock (https://www.kuberdock.com/), which is made by CloudLinux, and works similarly to SandStorm, but can pull from over 70,000+ docker containers. What’s more, it integrates with CPanel and WHCMS, which could be huge for us given we come from the web hosting at scale perspective these days :) It’s still in beta, but we are pretty excited by this avenue as well.

    I think the bigger point for me regardless of either one of these is that the vision of a wide-range of technologies running on a variety of stacks will now be readily available to folks. And installing them will be dead simple.

    As for the Calypso news it just reinforces for me everything Kin lane has been telling us for the last 3 years :)

    • I am with you that Sandstorm doesn’t play well with CPanel. I haven’t played with Kuberdock, so I can’t comment too much on it, but I am completely compelled by how easy Sandstorm is. Do we want people have access to more applications or do we want to make them to have an easy way of managing them? The UX of Sandstorm is vastly superior to the current CPanel.

      One way I could see it working is a secondary product offering to domains/CPanel. Let’s throw out the domain for a second and say Sandstorm is more like… Bit.ly. It just randomly generates a link that goes to a “thing.” That’s sort of what Sandstorm is. So while Sandstorm might not be the application for your digital presence (the domain)–that will certainly be where Kuberdock comes in handy–it might be the storefront for a bunch of web apps that doesn’t necessarily need a pretty address because they aren’t necessarily public facing spaces (like Slack/Trello) but are incredibly accessible to anybody.

      Kuberdock may be totally awesome but is it going to revamp the CPanel? I’m not sure. The workflow of creating a subdomain before installing an app (rather than that being an integrated process) still feel antiquated for instance.

      One thing I won’t is argue is that Kin is correct. :-)

      • jimgroom
        As far as Sandstorm being just in time applications for specific chores, that makes total sense. What’s more, they’ll probably figure out the domain mapping stuff. But in terms of a wide range of applications available, Docker is remains pretty intriguing to me. There was almost immediately a Calypso Docker container available for us to play with, which was very cool. Fact is, it isn’t one or the other. But my focus, and for obvious reasons, is working within a dashboard where we can integrate the work we have done so that we can provide more possibilities. This could be Sandstorm’s Oasis that is run akin to a subdomain model like a WordPress multisite. Whereas Kuberdock would enable a wide range of applications through CPanel. In terms of the integration details, that is part of the beta. But I think the solution is to abstracting and pulling out elements of Cpanel into a far more simplified dashboard that is customizable for a a particular community would be the goal (in that same dashbaord you could alos have Dandstorm apps, Docker containers, etc.). CPanels integrations with Kuberdock (and viceversa) points to the fact this will be possible fairly soon. Good news all around.
        • “But I think the solution is to abstracting and pulling out elements of Cpanel into a far more simplified dashboard that is customizable for a a particular community would be the goal”

          Yep, I think you hit the nail on the head right there. Like Holden’s answer isn’t necessarily Calypso, mine isn’t necessarily Sandstorm. I’m more interested in how streamlined the management process is with the tool and think it serves as a model for what CPanel could be (containers + user friendly dashboard). It makes it simple to manage apps that could happen to sit on a domain rather than getting stuck into the domain/server management tools (which are very necessary to have availability but not always desired).

  • hapgood
    Great post, Adam. Having worked with Node.js and Javascript front-ends that use Node.js backends, I’d just add one theoretical note that’s really important to me — the fact that meaning is made on the client end. This means that the client and the server can be developed separately, and I’m not forced to use the server’s fossilized view of the data.

    This is not in Calypso, as far as I know, but as you mention, it’s not about Calypso, it’s about the model that Calypso has adopted. Once you make your editing and viewing tools fully dependent on an open API you’ve committed to this path.

    What comes out of this, potentially, is, well, federation. (You knew it was going there, right?). I can pull pages as data from multiple sources and integrate them into my own custom view — if Calypso is committing to using only the released APIs to do this, then we can make a federated read-write system too. We can start looking at *cross-site* architectures that involve 25% of the world’s websites.

    You can do this with PHP, for sure, just as you can write plain old server scripts with Node. But the style of Node + js frameworks is that this separation between display/navigation and data is taken to the nth level — there’s no reason to use Node unless you’re going to push display logic to the client and that’s the difference, so now you can replace the first one here with the second…..the client gets it’s power back, which puts you, the user, back in control. (and yes, I know this is far off, but it’s the best hope we have to reverse the tide of the last 10 years).