By Asheesh Laroia - 22 Jan 2015
The Sandstorm wiki is now world-writable, and I made a new page to help people get involved.
I realized the wiki should be world-writable when phildini remarked on IRC that the porting guide could give better advice for Mac OS users. What I really wanted to do was ask him to update the page himself, but I discovered I would first need to grant him access. So I made it writable by anyone logged into GitHub, and I configured a script to email a mailing list whenever it gets changed. Within forty-eight hours, I saw a new person contribute to the wiki!
The wiki is one of the things I mention on the new Get Involved page. In writing it, I took a lot of inspiration from Meteor’s – it’s a particularly great one. My goals are to showcase all the ways to contribute to Sandstorm across diverse skill sets and to have a contextualized listing of all the places that project members communicate. I’m excited to watch the community build great things on Sandstorm, and extraordinarily grateful to people who share the platform with friends. I think the most important thing Sandstorm needs right now is more people knowing about the project.
So please give it a read and get involved!
By David Renshaw - 21 Jan 2015
When I write software, Git is usually at the core of my workflow. Therefore I’m particularly excited to announce today that we are releasing not one but two Git apps for Sandstorm.
With either of these apps, you can host a Git repository on a Sandstorm server, connect to it with a Git client, and browse it through a web interface. Furthermore, both apps make it easy to share access to a repository without any need to manage SSH keys.
The first app is a simple wrapper around GitWeb, the minimalist Perl CGI script that comes bundled with Git.
The second is a port of GitLab, a sophisticated Ruby on Rails app whose features include an issue tracker, a wiki, and an editor that allows you to compose and submit commits entirely from a web interface.
Both apps can now be found on the Sandstorm app list. If you don’t have your own server already, try the demo.
These two apps bring into focus some distinguishing characteristics of the Sandstorm platform.
Web software today tends to consist of monolithic, centralized services – at least when viewed from a user’s perspective. As the number of users grow, the demand for scalability and easy deployability can drive developers to put a lot of effort into modularizing backends. So the software often gets split into reconfigurable components like databases, caches, webservers, and message queues, and we see lots of clever ways to organize and orchestrate all of these things. However, as far as the user can tell, the only benefit is that, well, the service still works.
Sandstorm enables a more fundamental kind of modularization. Because it is decentralized and carefully designed to take full advantage of Cap’n Proto’s object-capabilities, Sandstorm allows web software to be split into fine-grained components along user-facing concerns. The components can be so finely grained, in fact, that scalability ceases to be a major concern. When each app instance (a “grain” in Sandstorm jargon) contains only a single document, app developers can instead focus on user-facing functionality, and can start thinking seriously about cooperation between apps.
And that’s why we’ve set up the GitWeb and GitLab apps to provide only a single repository per grain. This setup means that sharing a Git repository with another user through these apps works just like sharing anything else in Sandstorm. Although it does imply that some GitLab features, like forks and merge requests, are not supported within our port, it also means that once we’ve fully implemented Sandstorm’s Powerbox interface for sharing capabilities between grains, “fork” and “merge request” can be actions that are allowed to take place between instances of any Git app.
By Kenton Varda - 15 Jan 2015
Lately, some of you may have noticed that Sandstorm’s daily meeting notes have often contained the ill-defined bullet point “business crap”. Today we’re finally able to share what that meant: we have secured $1.3M in seed funding from a great group of venture capitalists and angel investors, led by Quest Venture Partners.
When we decided to raise VC money, we insisted on doing it in a way that keeps us aligned with our original grassroots goals. We needed a business plan that allowed us to make money by protecting our users’ privacy, not by violating it. We’re happy to say that we found one.
As it turns out, every problem individuals have with increasing centralization of “the cloud”, businesses have ten-fold. Businesses, too, worry about things like privacy, security, being able to customize their software to their needs, and being able to smoothly integrate software from multiple vendors. In fact, businesses worry about these things far more than the average user. As a result, many businesses – especially the largest enterprises – maintain massive in-house compute infrastructure, at heavy cost. Securing this infrastructure has proven difficult, as attacks on Target, Sony Pictures, and so many other large companies have proven. We and our investors believe that the technology we are building in Sandstorm can solve these problems – and any time you solve a problem for big businesses, money is not far away.
We like this objective because it keeps us totally aligned with our users. In fact, we are now arguably more aligned with the community than before. Whereas previously there had been a lot of pressure on us to focus on our subscription-based managed hosting option as a way to get revenue, our immediate goal now is just to develop and prove the platform. That means that self-hosted users are just as important to us as paying subscribers. To that end, the first thing we have done with our new money is to hire Asheesh Laroia, a long-time self-hosting and Free Software enthusiast, whose main focus will be improving Sandstorm’s self-hosting experience. To be clear, everything you need to run your own Sandstorm server will always be free and open source, still developed in the open.
To fund Sandstorm’s development, we will be also starting a separate project – codenamed “Blackrock” – aimed specifically at building tools to maintain large Sandstorm clusters integrated with common enterprise-oriented infrastructure (such as Active Directory). Some of this may not be open source, but if it turns out that a feature of Blackrock is of interest to the community at large, we will look to move that code into Sandstorm proper. I personally hate the idea that some of my code may not be open – I have been releasing all of my personal code under open source licenses since high school – but I am happy that it means we can fund heavy development of the open source Sandstorm platform, without the need for advertising or data mining.
Back in August, the community gave us $58,929 to make Sandstorm happen. We could not have gotten to this point without the help of our Indiegogo backers, and we are deeply grateful for your support both during the campaign and since. You helped us prove that a decentralized internet is something people want. Now that we’ve raised VC money, we want to pay forward your investment in us.
First, all of our Indiegogo perks will of course be honored. T-shirts and stickers have been sent out already (if you didn’t get yours, please let us know), the App Committee has been actively meeting, and our managed hosting option will open later this year.
We would also like our backers’ help in growing a marketplace that makes open source web applications viable. With this new funding, we are able to build a marketplace in which open source Sandstorm apps will be sold on a “pay what you want” basis, with all proceeds going to the developer. To honor our backers, we will be providing credit in our marketplace equal to backers’ contribution on Indiegogo. Use this credit to fund any open source web application that matters to you. Yes, you can choose your own project – even if it contains only one line of code – but we hope you’ll spread the love and choose a project that is advancing the decentralized web.
With our new funding, we will be able to implement all of the “stretch goals” listed in our Indiegogo campaign. We don’t have a timeline for these yet, but they are coming! Here they are, for those that don’t remember:
While Sandstorm is getting easier to run on your own Linux machine, many people don’t want the hassle of maintaining a physical server. Thus, we are planning to provide subscription-based managed hosting option as well.
For those who missed the Indiegogo campaign, we are now accepting pre-orders for this service. Pre-ordering now will get you free access to our beta (when it is ready); you will not actually be charged until the beta is over.
We regularly post internal meeting notes and answer questions on the sandstorm-dev mailing list, and we are usually available to chat on IRC (#sandstorm on freenode). Feel free to come talk to us in either place!
Want to write a Sandstorm app, or port an existing app to Sandstorm? Check out the Porting Guide and drop us a line in sandstorm-dev if you get stuck.
Who controls Sandstorm?
Sandstorm and Cap’n Proto are properties of Sandstorm Development Group, Inc., a company founded by Kenton Varda and Jade Wang. Kenton is the CEO. Jade is the President. The Board of Directors is Kenton and Jade. The company is majority-owned by Kenton and Jade, with room for additional financing rounds without losing that majority.
When will managed hosting be available?
Software project time estimates are always autorectumatic, but we anticipate the beta will open in Summer of this year. Once the service is stable, secure, and backed up, it will come out of beta and we will start charging for it. To get a spot in the beta, pre-order now (we won’t actually charge you until after the beta is over).
By Jade Q Wang - 14 Jan 2015
I’m excited to announce that starting today, pre-orders for Sandstorm managed hosting are now open.
All pre-order customers will enjoy free access to the beta once it’s ready, and beta invites will be distributed first-come-first-serve as capacity ramps up. Backers who pre-ordered Sandstorm hosting on Indiegogo will get beta access first, followed by the new pre-orders. Oh, and I’ll also send you some sand cat stickers in thanks!
Of course, you don’t need to use our managed hosting. You can always run Sandstorm on your own Linux box, using only open source code. We provide managed hosting so that those who don’t know how to run their own server – or just don’t have the time – have a way to run Sandstorm.
Whether or not you have any questions or feedback, come hang out with everybody in #sandstorm on freenode IRC!
Missed out on other perks during the Indiegogo campaign? Come get a shirt and some stickers at an upcoming meetup!
Thursday, January 15, 2015. (tomorrow) Pittsburgh, PA: David Renshaw will be speaking about Cap’n Proto and Sandstorm at ShowClix offices for the Engibeer.in meetup. Free local craft beer tasting and other tech talks too! RSVP
Tuesday, January 20, 2015. Cambridge, MA: Asheesh Laroia will be at Clover Harvard Square, along with other folks interested in web app self-hosting. First drink on Sandstorm! RSVP
By Kenton Varda - 14 Jan 2015
When using Sandstorm’s upcoming managed hosting service, your resource usage will be limited in two important ways:
So, what exactly are compute units? Technically speaking, a CU can also be described as a “gigabyte-RAM-hour”: using a gigabyte of RAM for one hour consumes one CU. Or, alternatively, using 100 MB of RAM for 10 hours, or using 10GB of RAM for six minutes, is also one CU.
Practically speaking, think of your CU quota like the battery on your phone. Some apps, when they are running, use more CU than others. Sandstorm aggressively shuts down apps when they are not in-use, so apps will only consume CU when you are actively using them (e.g. when you have them open in your browser). As a rule of thumb, we find that many apps use about 1 CU for every 5-10 hours of active use. Some apps – especially ones with servers written in ahead-of-time compiled languages like C++, Rust, or Go – may use far less, while particularly inefficient apps may use a bit more. You will be able to check your CU level and see which apps are using it by clicking the CU indicator in the top bar.
Note that when you use an app to publish a web site to a separate domain – such as Ghost or WordPress – Sandstorm caches the page content and serves it statically. Therefore, the app does not start up and does not consume CU when a guest merely visits your site; CU is only used if the visitor does something that changes the site (like leaving a comment) or when you open the app’s administrative interface.
For our managed hosting service, you will receive a monthly CU allowance. Those who sign up for the “standard” plan (currently slated for $6 / month) will receive 200CU per month. That equates to 1000-2000 hours of using a typical app, which is more time than a month actually has! We expect that most users will never come anywhere near hitting their CU quota.
But what happens if you do hit your quota? We said your CU is like a battery, but it’s like a battery that is always charging. When you first create your account, your CU battery starts out full. When it is not full, it recharges at a rate such that over the course of a month it will recharge equal to your monthly limit. So if you run out of CU, go take a walk, and when you get back you’ll have some more. And if you run out often, consider upgrading to a larger plan. :)