4 ms·

Sandstorm founder here. Thanks for your feedback -- I definitely understand the concern, and it's something I've thought about a lot. To be clear, we've always

by kentonv 11y ago

Sandstorm founder here. Thanks for your feedback -- I definitely understand the concern, and it's something I've thought about a lot. To be clear, we've always been upfront about our intent to sell "enterprise add-ons" to the self-hosted solution. See this post, from January 2015: https://sandstorm.io/news/2015-01-15-sandstorm-1.3M-seed-round-pay-it-forward https://sandstorm.io/news/2015-01-15-sandstorm-1.3M-seed-rou... It is our intent that any feature which is broadly useful to someone running a personal server should be in the free version. There is a gray area, of course: some people actually run LDAP servers in their homes. But we're pretty sure that the vast majority of personal users won't be interested in these business-oriented features. And we have a lot of potential features to implement that businesses need but individuals absolutely don't (examples: legal discovery tools; HIPAA compliance; cluster management), so there's really no need for us to hold back the more broadly-useful features for leverage. I'd actually argue that it would be very much against our interest to "hamstring" the personal version of the product, not just morally but strategically. Strategically speaking, we aren't going to make much money off personal users no matter what pricing we impose. Business is where the money is. Personal users are incredibly important, though, because the kinds of enthusiasts who would run their own Sandstorm server are also the kinds of people likely to develop apps and/or advocate for Sandstorm to their employer. It would be shooting ourselves in the foot to do anything to turn off those users. Of course, strategy isn't the only thing holding me back. Morally speaking, I personally started Sandstorm to make open source web apps viable, not to get rich. See: https://sandstorm.io/news/2014-07-21-open-source-web-apps-require-federated-hosting https://sandstorm.io/news/2014-07-21-open-source-web-apps-re... To be honest, I would actually argue that our hosting service is a bigger conflict of interest than Sandstorm for Work. It could make us inclined to make it hard to set up and maintain Sandstorm -- why spend time making installation painless and updates automatic if it only benefits the people who aren't paying us? Sandstorm for Work is actually the exact same build as the free version, with the same installation process, so now we're incentivized to keep it really easy -- and indeed, last night we shipped an overhaul of our first-time setup UX, which we did for the Sandstorm for Work launch, but it applies to the free version too. All in all, of all the options we've considered, I think this approach actually gives us the best alignment of incentives.

sytse 11y ago
Well put! I applaud you for making the for work version open source. At GitLab we found that this helped during the introduction but was confusing to customers in the long run. I'll watch closely how Sandstorm handles this and we'll try to learn. Congratulation on this move today, I think it makes a lot of sense. For us the on-premises premium version allowed us to become sustainable, I hope it will do the same for you.
e12e 11y ago
I'm uneasy about this too (the ldap part in particular). It's an odd sensation, when the first contribution you want to make to a great FOSS project is to fork it and work around a nagscreen and provide a channel for updates ... More generally, I really think a solid self-host federated login solution should be part of any project of Sandstorm's nature. Granted, there aren't really any pleasant out-of-the-box reasonably secure (as in, sane ldap schema permissions, tls-only) FOSS ldap solutions. In this regard Microsoft AD might still be the easiest option for many small businesses. Although Red Hat at least has a story here, that (thanks to being FOSS) should/does work across distributions. I certainly sympathize with the idea that it's hard to know where to draw the line for which features are "value-add", and how to charge for them in a mostly open platform. And I'm afraid I can't really come up with anything more constructive as an alternative right now. Still hope Sandstorm will continue to evolve, it's a very interesting product!
- kentonv 11y ago
  I think for an at-home setup, we should be able to come up with something much simpler and better-suited to the task than LDAP. I'm happy to add new and well-designed login systems to the free version. The main tricky requirement is that we want identities to be global -- that is, other people's Sandstorm servers should be able to authenticate you to the same global ID that your own server does. This is important so that it's possible to transfer grains between servers without all the user IDs changing (which probably makes the grain useless, if it stores user IDs at all). (Actually, LDAP doesn't even satisfy this requirement! But we figure corp users aren't as eager to participate in a federated network of personal servers.) One thing we want to add, for example, is public-key login, where your identity is your public key fingerprint. You login in by proving access to the private key. Though, this is something I'd only recommend for hardcore crypto nerds, since bad key management would be catastrophic. We should look into other options, too.

by kentonv 11y ago

sytse 11y ago

Well put! I applaud you for making the for work version open source. At GitLab we found that this helped during the introduction but was confusing to customers in the long run. I'll watch closely how Sandstorm handles this and we'll try to learn. Congratulation on this move today, I think it makes a lot of sense. For us the on-premises premium version allowed us to become sustainable, I hope it will do the same for you.

e12e 11y ago

I'm uneasy about this too (the ldap part in particular). It's an odd sensation, when the first contribution you want to make to a great FOSS project is to fork it and work around a nagscreen and provide a channel for updates ... More generally, I really think a solid self-host federated login solution should be part of any project of Sandstorm's nature. Granted, there aren't really any pleasant out-of-the-box reasonably secure (as in, sane ldap schema permissions, tls-only) FOSS ldap solutions. In this regard Microsoft AD might still be the easiest option for many small businesses. Although Red Hat at least has a story here, that (thanks to being FOSS) should/does work across distributions. I certainly sympathize with the idea that it's hard to know where to draw the line for which features are "value-add", and how to charge for them in a mostly open platform. And I'm afraid I can't really come up with anything more constructive as an alternative right now. Still hope Sandstorm will continue to evolve, it's a very interesting product!

kentonv 11y ago
I think for an at-home setup, we should be able to come up with something much simpler and better-suited to the task than LDAP. I'm happy to add new and well-designed login systems to the free version. The main tricky requirement is that we want identities to be global -- that is, other people's Sandstorm servers should be able to authenticate you to the same global ID that your own server does. This is important so that it's possible to transfer grains between servers without all the user IDs changing (which probably makes the grain useless, if it stores user IDs at all). (Actually, LDAP doesn't even satisfy this requirement! But we figure corp users aren't as eager to participate in a federated network of personal servers.) One thing we want to add, for example, is public-key login, where your identity is your public key fingerprint. You login in by proving access to the private key. Though, this is something I'd only recommend for hardcore crypto nerds, since bad key management would be catastrophic. We should look into other options, too.