Tag Archives: tech

Too many beginners

Last weekend at FOSDEM I gave my “Write A Better Manual” talk. I got a question afterwards that I’ve never actually received before:

We’ve done such a great job of attracting new members to our community that it’s causing a problem. Our lead developers are spending all of their time mentoring beginners, and no code is getting written. What do we do?

Once I got over my “I wish I had your problem” moment, we had a great conversation about concrete ways that you can address this problem. And, of course, it is actually a problem, because it can lead to the demise of your project every bit as much as not enough new community members.

Here’s some things that you can do, even if you don’t have exactly this problem:

Turn the beginners into mentors

Someone has just come to your community, and asks a question. It’s one of the questions that you get every day, like “how do I find my IP address?” or “how do I connect to a wireless network?” or “where is the toilet?”

Rather than answering the question yourself, ask the not-quite-beginner to answer it. This does many things at the same time. It saves you the time and trouble of answering. It indicates your confidence that this person is part of the team. It lets this person know that it’s ok for them to start mentoring other people. And the next time the question is asked, you won’t even have to say anything – they’ll just answer it. You’ve taken the first step to making a mentor out of the mentee.

Take shifts

Mentoring beginners is amazingly rewarding, but it’s also exhausting. You shouldn’t have everyone doing it, and you shouldn’t have the same people doing it all the time. Take turns. Even go so far as making a rotation schedule – one week on, 3 weeks off. Your mentors will come back rejuvenated and ready to start up, and will get “off shift” just about the time that it’s starting to be frustrating.

Know when to quit

Even if you don’t take specific shifts, mentors should be told that they can, and should, take breaks. Mentoring is incredibly important, but it’s only part of your “job”. Work on code for 3 hours for every hour you spend answering questions on IRC. Or something like that. You’ll find that if you set yourself a specific quota of mentoring time, you’ll look forward to it more, and you’ll be more effective at it.

If you’re not good at it, don’t do it

Finally, some folks just aren’t that great at mentoring. Either they’re not very patient, or they’re not great at communicating, or maybe they’re just too valuable at writing the code or the docs, and should stick to that.

These people should be encouraged to stick to what they’re good at, because, frankly, some people do more harm than good when it comes to talking to beginners.

Celebrate your problem

But, at the end of it, recognize that most projects would love to have the problem you’ve got. Celebrate your beginners. Bring them along. Eventually, they will “graduate” and become the core of your community.

 

 

Project Leader

I was recently asked to write something about the project that I work on – RDO – and one of the questions that was asked was:

A healthy project has a visible lead(s). Who is the project lead(s) for this project?

This struck me as a strange question because, for the most part, the open source projects that I choose to work on don’t have a project lead, but are, rather, led by community consensus, as well as a healthy dose of “Just Do It”. This is also the case with RDO, where decisions are discussed in public on the mailing list, and on IRC meetings, and those that step up to do the work have more practical influence than those that just talk about it.

Now, this isn’t to say that nobody takes leadership or ownership of the projects. In many senses, everyone does. But, of course, certain people do rise to prominence from time to time, just based on the volume of work that they do, and these people are the de facto leaders for that moment.

There’s a lot of different leadership styles in open source, and a lot of projects do in fact choose to have one technical leader who has the final say on all contributions. That model can work well, and does in many cases. But I think it’s important for a project to ask itself a few questions:

  • What do we do when a significant number of the community disagrees with the direction that this leader is taking things?
  • What happens when the leader leaves? This can happen for many different reasons, from vacation time, to losing interest in the project, to death.
  • What do we do when the project grows in scope to the point that a single leader can no longer be an expert on everything?

A strong leader who cares about their project and community will be able to delegate, and designate replacements, to address these concerns. A leader who is more concerned with power or ego than with the needs of their community is likely to fail on one or more of these tests.

But, I find that I greatly prefer projects where project governance is of the people, by the people, and for the people.

Cacti and the Asus RT‑N66U

I discovered a few days ago, quite by accident, that the Cacti project is still quite alive and well. I don’t know why I thought it wasn’t. I thought it would be kind of cool to set it up to graph my network traffic here at home.

I have an Asus RT-N66U wireless router, which I’ve been very pleased with since I acquired it.

Step one was getting Cacti running, which has always been something of a challenge. The installation instructions, while extensive, miss a lot of prerequisites that you encounter along the way. (Install packages are not, apparently, available for CentOS7.) Notably, you have to install Spine (the stats collection daemon) from source, and it required the -devel version of several of the items that the docs mention. So, things like php-devel, mysql-devel, snmp-utils, which are not mentioned in the installation instructions. No big deal, but it did make the process a little longer, finding and installing these prerequisites.

Step two was getting file permissions set up correctly in my Apache httpd document directory. This turned out to be a combination of missing directories (log/ and rra/ in Cacti’s home directory) and the fact that my vanilla installation of php had logging turned off, so everything just silently failed. Those directories, once created, and ownership changed to the newly created cactiuser user, Cacti itself started running. Awesome.

Step three is enabling SNMP on the router, which isn’t hard, but is a little time consuming. Instructions for doing this may be found on the My gap in the void blog, and I will not copy them here.

Finally, there’s the step of getting Cacti to talk to the N66U. This turned out to be absurdly easy. Under ‘devices’, I clicked Add. I gave it the name and IP address of the router, and selected “Generic SNMP-enabled Host” from the Host Template dropdown, and pressed ‘Create’.

On the server, in the cactiuser’s crontab, add:

*/5 * * * * php /var/www/html/poller.php > /dev/null 2>&1

Then, click ‘New Graphs’, select the “select all” checkbox, and press ‘Create’.

Finally, under ‘Graph Management’, select the ‘select all’ checkbox, select ‘Place on a tree (default tree)’, and press go.

And, you’re done. Wait a few hours for data to accumulate:

graph_image

RetroPie

This weekend I set up my new Raspberry Pi with the RetroPie distribution, using the instructions and parts list from LifeHacker. I’ve been eyeing it for a while, and just hadn’t gotten around to it yet.

IMG_20160804_190526

It was very simple to get installed, but configuring the controller – I used an XBox360 USB controller – proved challenging. I ended up following the instructions in this Github issue to get it working.

Most of the games that I wanted are from the various Atari systems, and from the ZX Spectrum – systems that are long since obsolete, but the games are still a lot of fun.

 

Sensordrone

I’ve been reading some things about Sensordrone – the first commercially available functional Tricorder … sort of.

photo-full

It’s a multi-sensor device that communicates with your phone via bluetooth, providing a variety of environmental sensor information – temperature, humidity, lighting. presence of various gases, and so on.

It looks like the kind of thing that would be ideal for home automation or other “internet of things” automation.

Unfortunately, it’s at a price point – $200 – where I have to seriously consider what I’d actually do with it, which is, probably, not a whole lot.

What will be cool is when these kinds of sensors are so cheap to make that they’re in everything. Remember 10 years or so ago, GPS technology was still crazy expensive and now there’s a GPS chip in everything from your camera to your phone to your watch.

Conversation and Community, by Anne Gentle

I just started reading Conversation and Community by the amazing Anne Gentle. I’m a few dozen pages in, and already recognize that I’m sitting at the feet of a guru.

I’ve been doing documentation for 15 years, roughly, making it up as I go along. I’ve done pretty well, considering, with 8 or 12 books (depending on what you count), and large portions of the Apache httpd docs to my credit, but Anne has made a science of it, and I’ve been continually impressed with the way that she wrangles groups of people into producing great content in literally a few days.

I’ll have to write more, later, once I’ve finished the book. I find that books like this tend to clarify and focus things that I’ve observed, but never taken the time to really analyze, about documentation and “customer support”.

OpenStack User Survey (Juno Summit)

Last month at the OpenStack Summit in Atlanta, the highly-anticipated OpenStack user survey results were released. For reasons of respondent anonymity, the raw data of the survey will not be released, but rather just a summary of the numbers. Even with that, the new numbers are very interesting.

It should be noted that the results of any survey like this have to be understood in the light of the respondent sample set. People answering this survey are those who are somewhat engaged with the OpenStack Foundation, and (obviously) aware that there even is a survey. When software is available freely, like OpenStack, there is simply no effective way to contact everyone that’s using it, so we’re necessarily seeing only a small percentage of the total population, and have to hope that it’s a representative percentage. There’s also a lot of marketing of the survey in the various “camps” in the OpenStack ecosystem, trying to get people to fill out the survey. Here, too, we have to hope that this is roughly fairly distributed, and does not itself skew the results.

That said …

The results of the survey are here: http://www.slideshare.net/ryan-lane/openstack-atlanta-user-survey

As the RDO community guy, of course my initial interest was in the distribution of deployment OS platform, as well as the deployment tools.

Let’s start with OS.

*Note: Graph corrected – I had the wrong numbers in this earlier*

Note that since the survey combines paid and non-paid Ubuntu, it seems reasonable to combine CentOS and RHEL deployments. I’m sure that there won’t be universal agreement that that’s the right thing to do. So be it.

Compare these to the numbers six months ago:

We’re not comparing apples to apples here, but here’s a graph of all the combined deployments across the categories, in the 2014 survey:

Several interesting conclusions that I draw from these numbers. Although, again, we’re not comparing apples to apples, so I’m sure that other folks will interpret differently.

Overall, the Ubuntu to RHEL/CentOS split moved from 55/34 to 47/39, indicating, overall, a movement away from Ubuntu towards CentOS and RHEL as the preferred platform for OpenStack deployments.

More interesting, looking at the breakdown into poc/dev/prod categories, there’s an even stronger motion towards CentOS (and RHEL) as a preferred platform for *new* deployments. Looking at the versions deployed in production, it’s clear that once folks have something deployed, they leave it alone, with a pretty high number of people running versions that are as far back as Essex, Diablo, or even earlier.

On the deployment tool side, I think that the question could stand to be clarified. I wonder, of the people who indicate that they are using Puppet or Chef to do their deployment, whether they’re using another tool such as crowbar or packstack to run those tools, for example, or if they’re actually writing their own Puppet/Chef scripts. I would also have expected, just anecdotaly based on various conversations, to see devstack much further out in front. Perhaps I’m just talking to a rather unrepresentative group – which is, of course, why surveys like this are so useful.

Also of great interest to me is the distribution of industries. I need to do more work on comparing the numbers side-by-side, but the academic sector (the #2 industry) has grown against the previous survey, from 11 to 13%, and some other industries have also grown a little. The fact that IT is still far and away the largest consumer of this stuff seems to confirm everyone’s impression that we’re still very early days in this stuff, and the more we see it grow in non-IT industries, the more we’ll know that it’s here to stay. (It also seems likely to me that people outside of the IT sector are unaware that there’s even a survey to fill out.) So that’s something to keep watching in the next time around.

Happy 15th, OSCon

15 years ago, I attended the first OSCon, in Santa Clara, I think. I was there for the Perl content, and managed to pay my way by giving a full day tutorial on the Apache web server. Amazingly, they kept asking me to come back and do it again, and I gave one talk or another every OSCon until 2006, after which I skipped a few years. Last year I made it back to OSCon again, and I’ll be going this year too.

This will be my first OSCon when I have no speaking responsibilities at all, although last year I only had a BOF, not an actual session.

This year, I’ll be working the Red Hat booth, and the OpenStack pavilion, as well as, hopefully, a little bit at the Apache Software foundation booth. Between that, and various evening events, and various meetings, I expect this to be another OSCon where I don’t actually sleep. I can’t quite manage that like I used to in 1998. But I’m really looking forward to the conference this year, and seeing the folks that I only see at OSCon.

Will I see you there?