The Slack-IRC gateway is a trick to lock-in customers

Well, here is another reason to resist using Slack:

[…]when you use /me on the IRC gateway while in private chat with someone, Slack just drops the message on the floor and doesn’t deliver it!

The company brags about their IRC gateway to lure in more groups and teams, but Slack and IRC are two totally different beasts: there will always be an increasing amount of pieces that get lost in translation.

The Slack-IRC gateway is just a trick to lock more users into the walled garden. Resist!

Source: rjbs’s rubric: The Slack IRC gateway drops your messages.

How To Use Vagrant And Git To Develop A WordPress Theme

 

Sometimes I like to sit down and play with technology. My colleague Mike Shroder mentioned VVV a few weeks ago and I had to try it. Check out this tutorial I wrote on how to create a new WordPress site, use Vagrant and git to develop a new theme locally, then push the modifications to a live site running on DreamHost (but it could run anywhere else, really).

Source: How To Use Vagrant And Git To Develop A WordPress Theme

Why the OpenStack community voting process fails and how to fix it

Open source communities offer a lot of democratic participation. The idea that you contribute to a project and have a say in its governance is a powerful one.  When it doesn’t work, those same projects turn their backs on active contributors and discourage newcomers. The most recent OpenStack elections for Individual members to the Board of Directors is a strong example of how community voting fails and how to fix it.

This time I watched the elections from the distance, as much of an outsider as I have ever been. Now that the results are in, I’m very disappointed to see confirmed four Individual board members — half of the total — whose inaction during 2016 should have not granted them reconfirmation.

It’s also extremely sad to see more than a few very active individuals have not been elected.  Of the eight elected, only one works for a smaller company and only one is mostly an OpenStack user (seven are primarily OpenStack vendors). The Individual members of the OpenStack Foundation were added to the bylaws to keep large corporate interests in check, and clearly this doesn’t seem to be working.

The OpenStack community has a huge problem here: good behavior and personal investments to improve the project don’t get rewarded. On the contrary, affiliation with large companies, spammy promotion, and geographic proximity seem to be more effective at granting a seat on the board. This has discouraged participation already, as some backchannel conversations have confirmed. You have to ask yourself, why would someone like Edgar Magana do what he has done for the short time he’s been on the board, when almost-inactive members get the votes?

A couple of immediate actions can be taken to improve the situation. First, acknowledge that an issue exists at the Board level, where too few small organizations and users are represented. Then, stop tolerating abuse of community resources like planet.openstack.org and use of the OpenStack logo. Actions should have followed OpenStack Foundation’s COO Mark Collier reminder to be nice during the campaign. Mark wrote:

With respect to local user groups and web channels, I think they should remain neutral ground that are open to all local community members.

But then the OpenStack logo (that’s another problem, known and unsolved for many years) was used to promote a single candidate as ‘our APAC‘ candidate. Who’s we exactly? OpenStack AU with the logo of the OpenStack Foundation? From my cursory glance at the candidates, there were others in APAC region, but I bet those candidates didn’t have direct access to the OpenStack AU Twitter feed.

OpenStack Australia suggesting to vote for Kavit as 'our APAC candidate'

And the shared Planet OpenStack (which is syndicated to Reddit and other places) was inundated for a week by the same advertising. My attempt to limit the damage to the community and send a signal was blocked.

One more thing: make the pages of the candidates more meaningful. They’re too wordy now, start with the generic bio and offer no link to hard facts. How many of the 3,000 voters actually read their pages (I bet they don’t, and we can easily find out with Google Analytics)? Members pages should show facts, not generic intention to make the world a better place. I always had the vision to collect data from analytics tools and show those in the individual member pages. Stackalytics already offers a pretty comprehensive view of what each person does, not just code-relate but emails, translations, work on bugs, and I bet more can be added from OpenStack Groups portal.

Communities need constant supervision and nurturing, they can’t be left unattended because as quickly as they have formed, they fall apart or at the very least lose critical focus. OpenStack is under tremendous pressure and now more than ever needs dedicated contributors to keep the project at the center of attention.

Medium is “pivoting”

I’m glad to read Ev Williams finally admitting that:

the broken system is ad-driven media on the internet. It simply doesn’t serve people. In fact, it’s not designed to.

He’s a smart person, I’m sure the next iteration of Medium will be interesting, no matter what the outcome will be.

Source: Renewing Medium’s focus

Prototyping applications with Airtable

Gotta say: using spreadsheet as poor-man’s database makes me feel poor every time. Google Sheets is so convenient that everybody starts a new sheet to hold some information in a table. The problem is, sheets are so convenient that some sheets keep on starting again, and again. Soon the company has 20 sheets holding bad information. It’s the tragedy of the corporate wikis all over again.

Instead I’m one of the few who used to love Microsoft Access: I know, it’s bad as a database but to rapidly prototyping small applications it was awesome. As a poor-mans database, Access was at least credit-worthy compared to spreadsheets.

Unfortunately Google doesn’t have something similar to MS Access so when I discovered Airtable, I got really happy. I’ve prototyped a small application to keep track of conferences and call for papers. Finally I don’t have to keep entering the same data every year in a new sheet and I can keep tables in fairly normalized form. Nice stuff. I wish Google Apps buys it … and the cynical in me says: “so we can have dozens of similar databases instead of hundreds of similar spreadsheets (the same tragedy, at a smaller scale).”

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!

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.

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

Balancing IRC and email, the secret of success for open collaboration

Are seasoned contributors to OpenStack giving too much importance to IRC, and is that creating bad side effects in other areas of the community?

Since I started contributing more to working groups outside of the OpenStack upstream contributor community, I noticed that email is used in a limited way, with a couple of lists having either very low traffic or low signal/noise ratio. The email lists are often used to share calendar notifications for meetings and their agendas with often little to no discussions. Have we insisted so much in holding weekly meetings “like developers do” that now people think that email discussions are less important?

This weekend a couple of posts on Planet OpenStack talk about IRC: one very good source of information on how to use IRC better from Chris Aedo who suggests to stay more on IRC. He argues:

If you are interested in becoming an OpenStack contributor, having a persistent IRC presence might be one of the most important secrets to success. Anyone who spends time in one of the more active project channels will immediately see the value of synchronous communication here where problems are sometimes solved in minutes.

On the other hand of the spectrum Chris Dent who highlights the chaotic nature of IRC. He mentions that too  much IRC leads to:

no opportunity to be truly away, frequent interruptions, an inflated sense of urgency, and a powerful sense of “oh noes, I’m missing what’s happening on IRC!!!!”—but the killer is the way in which it allows, encourages and even enforces the creation and expression of project knowledge within IRC, leaving out people who want or need to participate but are not synchronous with the discussion.

This last point is crucial: not everybody can be online all the time, some of us have to sleep or go see a movie at times. IRC is often mentioned as a blocker to new community members. I advocate using a bouncer only to get personal messages, not to read the backlogs.

While synchronous communication is crucial for distributed collaboration, a sane habit of using email is as important. The OpenStack community has put so much emphasis on using IRC to hold weekly meeting and to resolve the most controversial conversations in real-time that some new comers now think that synchronous communication is more important than async email.

A sane balance of sync-async communication is more crucial to success of open source collaboration, mixing email and IRC (which is what most of OpenStack upstream developers do, by the way.)

All in all, I think there is also a need to teach people how to hold conversations via email, with proper quoting, no top posting and other nice things to do… but also email sorting and filtering client-side, what not to say (hint: “me too” messages are generally considered noise)… a lost art, as much as using IRC.