Why you should not use Slack for volunteer communities

Last night I was asked again to join a Slack channel during a community event and I lost it. I lost the patience for this constant push into a walled garden. I can accept that only at work. I don’t want my email to be given away to a company so they can brag about their growth rate… and for what in exchange? More work for me to signup, pay attention to terms of service, unsubscribe, remove notifications…

No! No! and NO! Community managers, don’t use Slack and please note:

  • It’s tacky to ask volunteers to surrender their email address to a third party who will use to send “occasionally” unrequested “news and announcements”. No, thank you.
  • It’s annoying to force your volunteers to signup for yet another service. Click click click click email click-verify tutorial etc. No, thank you.
  • It’s wrong to archive your volunteers conversations and credentials in a big fat place where the next criminal will grab them. Because you know it will eventually happen, right? No, thank you.

Slack works so well in work environment because it keeps history, it’s very good on mobile, its notifications can be fine tuned… it’s pervasive, and very effective… at work! But the last thing I want as a volunteer is to spend time to fine tune notifications for each and every group I join.

Also, you can’t expect volunteers to keep up with the history of a channel (hey, hello, hi, wazzup, thank you, great, awesome, gif, gif gif… ), so that Slack feature is not useful.  As a community manager, you should know that there is always one that abuses of the @here @channel @all shortcuts to ask moronic “support” questions in the most populated #general channel. There you have your daily “@all it doesn’t work!” even if there is a channel called #support.

Buzz off, and RTFM! I said it!

There are better ways, not intrusive, easy to start and quit when the meeting is done. Etherpads have chat: do the volunteer work, take notes, share links on the chat. If etherpad is too complicated, I’d accept Google Docs.

Do you just need a temporary channel to chat? Just create one on the fly with freenode web chat, mibbit or any other IRC on web. Hit it and quit it: chances are, the archives of your meeting are not going to be read by anybody anyway. Let your community focus on the asynchronous systems: email works well, forums, comments on your website etc.

You should not give away your community members : they’re not yours to give, in the first place!

VCs who miss the point of open source shouldn’t fund it | InfoWorld

People who believe that Apache is a competitor, OSI approves licenses that permit monopolization, Red Hat is a business that’s succeeded through artificial scarcity, and open source communities with diverse agendas are “broken” are not the people you want in your new open source business.

Well said. Via Simon Phipps on http://www.infoworld.com/article/3032120/open-source-tools/vcs-who-miss-the-point-of-open-source-shouldnt-fund-it.html

DreamHost Gives Free SSL/TLS Certificates with Let’s Encrypt

DreamHost has done the right thing, deciding to let go of a portion of its revenues in favor of free SSL/TLS certificates for everybody.

It’s a great pleasure to work for such a company, knowing every day that customers come first and revenues are a side effect. DreamHost may not be the multi-billion dollar juggernaut in the industry but the people here are helpful, nice, competent and believe in what they do.

Let’s Encrypt is another contribution to a free society, pairing up with the contributions Ceph, Astara and OpenStack, WordPress and many other free software/open source projects directly and indirectly sponsored by DreamHost.

Source: Free SSL/TLS Certificates at DreamHost with Let’s Encrypt

PS: we’re hiring a Cloud Storage engineer.

Meet OpenStack at FOSDEM 2016

The most important gathering of free software and open source enthusiasts in Europe is coming on Jan 30-31, in Brussels and OpenStack will have a table booth there, plus many talks.

I look forward to go there to get the pulse on the open source community regarding the abolition of Safe Harbor provision, and how that impacts users of US-based public clouds, like DreamHost. It’s a complicated issue that I’ve just started looking into. One of the talks I’ll make sure to attend to is Rosario Di Somma’s talk about Magnum in production: he’s been evaluating Magnum for DreamHost and he’ll share the first results of his investigations.

On the OpenStack side of things, Adrien Cunin is the main point of contact and he’s looking for volunteers to preside at the official OpenStack table at FOSDEM. If you have holes in your agenda, please consider adding your name to the etherpad.

Developing apps on OpenStack is still too complicated

Yesterday’s meeting with the OpenStack App Developer Working Group proved that new developers approaching OpenStack enter a system designed to make them fail.

The community seems to be distracted to uncover new problems while the old and known problems are not being addressed. I’m running for a seat on OpenStack Foundation Board: if you care about the developer’s experience, consider voting for me (search your inbox for OpenStack Foundation – 2016 Individual Director Election, you can also change your vote.)

The App Developer Working Group drafted a detailed analysis of the app developer experience with major cloud providers AWS, Azure and Google Compute and compared such experience with Rackspace Cloud. It’s a great piece of work.

The first thing you notice in the report? The team at Intel who ran the analysis chose Rackspace as an ‘OpenStack reference cloud’.  That choice is debatable but during the meeting when we discussed alternatives, it became clear that there is no good choice! There is no vanilla OpenStack implementation when it comes to application developers, they’re all snowflakes (as Randy Bias put it)… All of the public clouds in OpenStack Marketplace have made choices that affect, one way or another, app developers. If we want to assess the whole development experience on OpenStack, we need a different framework.

As an open source community we can’t compare AWS, Azure and Google Compute to either all of OpenStack public clouds or only one. Powering up TryStack to be an app developers playground wouldn’t really work either.

This is a much larger conversation: we need to discuss more on the User Committee mailing list, do less in-person meetings, share intentions online with others before turning them into actions and waste time.

I’m concerned by the lack of focus within the community: when operating OpenStack became a visible issue, the whole community focused on helping operators out. We need to do the same for app developers.

What is an OpenStack Powered Compute?

The OpenStack Technical Committee voted a resolution suggesting to the OpenStack Board to modify the definition of “OpenStack Powered Compute” to include statements such as

An `OpenStack Powered Compute`_ Cloud MUST be able to boot a Linux Guest

This is quite a change in OpenStack DefCore efforts, since as Rob says

The fundamental premise of DefCore is that we can use the development tests for API and behavior validation

DefCore has always been about the OpenStack API and carefully avoided checking the implementation of clouds, leaving enough space for vendors to differentiate their products without harming consumers. An ironic twist of fate is now forcing the whole program to take a stand on implementation, too.

Stating that an OpenStack cloud MUST be able to boot a Linux Guest  is the most controversial and I see why the TC is going into this direction: as a OpenStack user, I expect to be able to upload my images in any OpenStack cloud. Given that Linux is the OS of choice for the vast majority of today’s cloud workloads, booting my Linux image is a must have. It’s a practical choice and one that makes a lot of sense.

The problem is that forcing implementation details by the TC is a slippery slope. Will the TC suggest also that any OpenStack cloud must offer a routable IP or boot a VM in less than 5 seconds or that flavor names are always the same across all OpenStack clouds? Granted, all these requests make sense from the perspective of at least some users: there are already lots of unnecessary complications for putting workloads on OpenStack right now.

The question is if those mandates make sense for OpenStack as a whole and I’m not convinced they do. I tend to lean towards two complimentary positions:

  1. make sure that OpenStack Compute Powered clouds are transparent and their behavior is discoverable. Like the OpenStack Foundation exposes the results of the DefCore API compatibility on the Marketplace, I think DefCore should test the implementation of the clouds, public clouds especially and expose the results. This way a user would know that a cloud passes DefCore tests, runs OpenStack upstream code (as done now) and allows uploading/booting Linux guests, offer IPv6 by default, boot in x seconds, has XYZ flavors, allows custom flavors, etc.
  2. DefCore should consider public clouds, hosted private clouds and distributions as different beasts. To me it makes more sense to expect a public cloud to allow uploading Linux guests than mandate the same for a private clod… even less sense for a distribution. The buying process for these is different and the needs for users are different, too.

Thoughts?

I’m a candidate for OpenStack Foundation Board of Directors: if you like what you read, remember to vote for me at the 2016 elections