Safe as Milk

Summer vacations – not the farmer’s fault!

Episode 1 in a series “Things that are the way they are because of constraints that no longer apply” (or: why we don’t change processes we have invested in that don’t make sense any more)

I posted a brief description of the Five Monkey experiment a few days ago, as an introduction to a series someone suggested to me as I was telling stories of how certain things came about. One of the stories was about school Summer vacation. Many educators these days feel that school holidays are too long, and that kids lose knowledge due to atrophy during the Summer months – the phenomenon even has a name.  And yet attempts to restructure the school year are strongly resisted, because of the amount of investment we have as a society in the school rhythms. But, why do US schools have 10-12 weeks of Summer vacation at all?

The story I had heard is that the Summer holiday is as long as it is, because at the origins of the modern education system, in a more agrarian society, kids were needed on the farm during the harvest and could not attend school.I do like to be accurate when talking about history, and so I went reading, and it turns out that this explanation is mostly a myth – at least in the US. And, as a farmer’s kid, that mostly makes sense to me. The harvest is mostly from August through to the beginning of October, so starting school in September, one of the busiest farming months, does not make a ton of sense.

But there is a grain of truth to it – in the US in the 1800s, there were typically two different school rhythms, depending on whether you lived in town or in the country. In town, schools were open all year round, but many children did not go all of the time. In the country, schools were mainly in session during two periods – Winter and Summer. Spring, when crops are plated, and Autumn, when they are harvested, were the busy months, and schools were closed. The advent of compulsory schooling brought the need to standardise the school year, and so vacations were introduced in the cities, and restructured in the country, to what we see today. This was essentially a compromise, and the long Summer vacation was driven, as you might expect, by the growing middle class’s desire to take Summer holidays with their children, not the farming family’s desire to exploit child labour. It was also the hardest period of the year for children in cities, with no air conditioning to keep school classrooms cool during the hottest months of the year.

So, while there is a grain of truth (holidays were scheduled around the harvest initially), the main driver for long Summer holidays is the same as today – parents want holidays too. The absence of air conditioning in schools would have been a distant second.

This article is US centric, but I have also seen this subject debated in France, where the tourism industry has strongly opposed changes to the school year structure, and in Ireland, where we had 8-9 weeks vacation in primary school. So – not off to a very good start, then!

The five monkeys thought experiment

The (probably apocryphal) five monkeys experiment goes like this:

Five monkeys are placed in a cage. There is a lever, which, if pulled, delivers food. The monkeys soon learn how it works, and regularly pull the lever.

One day, when the lever is pulled, food is still delivered to the puller, but all the monkeys in the cage get an ice-cold shower for a period of time. The monkeys quickly learn the correlation between the lever and the cold shower, and stop any monkey from getting to the lever.

After a while, one of the monkeys is removed, and replaced by a new monkey. Out of curiosity, the new monkey tried to pull the lever, and was beaten into submission by the other monkeys. Progressively, more of the original five monkeys are removed, and replaced with new monkeys, and they all learn the social rule – if you try to pull the lever, the group will stop you.

Eventually, all of the original monkeys are gone. At this point, you can turn off the shower, secure in the knowledge that none of the monkeys will pull the lever, without ever knowing what will happen if they do.

A funny anecdote, right? A lesson for anyone who ever thinks “because that’s the way it has always been”.

And yet, there are a significant number of things in modern society that are the way they are because at one point in time, there was some constraint that applied, which no longer applies in the world of air travel and computers. I got thinking about this because of the electoral college and the constitutional delays between the November election and the January inauguration of a new president – a system that exists to get around the logistical constraints of having to travelling distances on horseback. But that is far from the only example.

This is a series, covering each of the examples I have found, and hopefully uncovering others along the way, and the electoral college will be one of them. First up, though, will be the Summer school vacation.

1. Summer vacations
2. QWERTY keyboards
3. Railway gauges
4. The Electoral College

The Dummies’ Guide to US Presidential Elections

The US presidential primaries

For those following the US presidential primaries from a distance, and wondering what is happening, here’s a brief dummies’ guide to the US presidential primaries and general election. It’s too early to say that Trump has won the Republican primary yet, even though (given his results and the media narrative) he is a strong favourite. To learn more than you will ever need to know about US presidential primaries, read on.

Primaries elect delegates

The presidential candidates are elected by the major parties at their party conventions, held during the Summer before the election. The primary elections are one way that the parties decide who gets to vote in the convention, and who they vote for.

Both parties have the concept of pledged and unpledged delegates – if you are pledged, then your vote in the 1st ballot of the nomination election has been decided in the primary. If you are unpledged, then you are free to change vote at any time. The Democrats have about 15% of their delegates unpledged, these are called superdelegates. The Republican party has about 170 unpledged delegates, representing about 7% of the total delegate count. Each state decides how to award pledged delegates, with a variety of processes which I will describe later.

If no candidate has a majority of delegated on the 1st ballot, then the fun starts – delegates are free to change their affiliation for 2nd and further ballots. This scenario, which used to happen often but now happens rarely, is called a contested or brokered convention. The last brokered convention was in 1952 for the Democrats, and 1948 for the Republicans. We have come close on a number of occasions, most recently 2008 for the Democrats, and 1976 for the Republicans.

Read the rest…

Targeted selection for job interviews

A post by Amanda McPherson about her best interviewing tip over on LinkedIn got me thinking about an interview technique I was taught while on the GNOME board many years ago:

Focus on behavior. In jobs related to product management, business development, sales, marketing or communications, you  have people who are verbally skilled. Ask them anything and you will likely get a good verbal response, but that doesn’t mean it’s true. Focusing on behavior — how they follow up, how and when they respond to your emails and questions, how they treat you vs others on the team for instance — yields more accurate data of how they will be on a daily basis.

She quotes the story of a Charles Schwab executive who would take candidates to breakfast interviews, and ask the restaurant to mix up the order deliberately – just to see how they would react to the stressful event.

The technique, which was taught to the GNOME board by Jonathan Blandford, goes one step further. The principle of targeted selection is that the best predictor of future behaviour is past behaviour. So if you are hiring someone to manage a team, ask about a time they were a manager in the past. If you need someone who can learn quickly in a new and fast moving domain, ask them about a time they were in a similar situation. Then dig deep for details – what did they do, how did they interact with others, how effective was the outcome of the situation?

As an example: if you want to know how someone reacts under pressure, ask about a time that they were working on a project that ran late. Ask them to describe the moment when they realised that they were not going to make the release date on time, on quality, as planned. Then ask how they reacted – did they reduce scope, fight for a schedule extension, add people, get everyone working weekends? Was there a post mortem after the project shipped? Who took the lead on that? How were the lessons applied in the next project? You can use a line of questioning like this to identify the people who will power through obstacles, regardless of the cost; people who are more consensual, but may lack decisiveness; people who seek help versus taking on too much burden. This type of insight is gold-dust when you are evaluating a candidate.

Some other ideas for questions:

• If you want someone who can ramp up quickly in a new area, ask about the last technology they discovered and became expert on. Then ask about the early days – was their instinct to read blogs, books, tutorials? To follow practical labs? To pay for training? Did they seek out people to ask questions and share knowledge? How did they evaluate where they were in the learning process? Have they stayed active and learning, or did they stop once they had enough knowledge to do the job? There is no right answer, but the approach they took will give you an idea of how they would attack a similar challenge in the future.
• If inter-personal relationships are key to success in the job, dig into a time they had a significant disagreement (with a boss, with a subordinate, with a colleague, with someone in a community project) – something meaningful and important to them. How did they go about arguing their case? Was winning more important than getting a good solution? How important was the relationship to them?
• If organisational skills are key: ask for an example of a time when they had to clean up after someone else. How did they go about draining the swamp? What do they say about the former organiser? How did they balance organising the existing system with allowing people to interact with the system and continue doing their jobs?

It isn’t just prospective employers who can use this technique to have better interviews. For candidates, this method can be awesome to allow you to prepare and take ownership of an interview. Look at the job requirements and required experience. When were you in a situation when you got to show the skills required? What were your actions, and what were the results?You can tell a story about your experience that hits all of the job requirements, even if your interviewer is not asking questions about it.

Go one step further: interview your interviewer! Think about the situations in the past where you have been successful and unsuccessful, and come up with your requirements – take that knowledge into the interview, and ask questions to check whether the position is a good match for you. Interviews are a two-way street, and you are interviewing the company as much as they are interviewing you. Ask interviewers when they were confronted with certain situations, and dig into their experiences as employees of the company. Is this a company that expects you to work weekends to meet unrealistic deadlines? Are you thrown a life buoy and expected to sink or swim? Is there a strict hierarchical structure, or are everyone’s perspectives heard and respected? Is there mobility within the company, or do people hit a developmental ceiling?

The great thing about this line of questioning is that it is not accessing the hypothetical side of the brain – you are not getting the idealised “I would…” answer where infinite time and resources, and everyone’s buy-in can be assumed. You are accessing memory banks, and the more details you get, the closer you get to the truth of how the person reacts. Especially great for providing insights are trade-offs, where there is no right answer – when two people want different things and you are there to adjudicate or be the intermediary, when you have to choose between two top priorities, when you only have enough time to do one of the three things that are important. In situations like that, you can really get insight into the approach and mentality of candidates, and also help candidates judge the culture and priorities of a company.

SDN/NFV DevRoom at FOSDEM: Deadline approaching!

We extended the deadline for the SDN/NFV DevRoom at FOSDEM to Wednesday, November 25th recently – and we now have the makings of a great line-up!

To date, I have received proposals about open source VNFs, dataplane acceleration and accelerated virtual switching, an overview of routing on the internet that looks fascinating, open switch design and operating systems, traffic generation and testing, and network overlays.

I am still interested in having a few more NFV focussed presentations, and one or two additional SDN controller projects – and any other topics you might think would tickle our fancy! Just over 24 hours until the deadline.

SDN/NFV DevRoom at FOSDEM 2016

We are pleased to announce the Call for Participation in the FOSDEM 2016 Software Defined Networking and Network Functions Virtualization DevRoom!

Important dates:

• Nov 18: Deadline for submissions
• Dec 1: Speakers notified of acceptance
• Dec 5: Schedule published

This year the DevRoom topics will cover two distinct fields:

• Software Defined Networking (SDN), covering virtual switching, open source SDN controllers, virtual routing
• Network Functions Virtualization (NFV), covering open source network functions, NFV management and orchestration tools, and topics related to the creation of an open source NFV platform

We are now inviting proposals for talks about Free/Libre/Open Source Software on the topics of SDN and NFV. This is an exciting and growing field, and FOSDEM gives an opportunity to reach a unique audience of very knowledgeable and highly technical free and open source software activists.

Topics accepted include, but are not limited to:

SDN:

• SDN controllers – OpenDaylight, OpenContrail, ONOS, Midonet, OVN, OpenStack Neutron,Calico, IOvisor, …
• Dataplane processing: DPDK, OpenDataplane, netdev, netfilter, ClickRouter
• Virtual switches: Open vSwitch, Snabb Switch, VDE, Lagopus
• Open network protocols: OpenFlow, NETCONF, OpenLISP, eBPF, P4, Quagga

NFV:

• Management and Orchestration (MANO): Deployment and management of network functions, policy enforcement, virtual network functions definition – rift.io, Cloudify, OpenMANO, Tacker, …
• Open source network functions: Clearwater IMS, FreeSWITCH, OpenSIPS, …
• NFV platform features: Service Function Chaining, fault management, dataplane acceleration, …

Talks should be aimed at a technical audience, but should not assume that attendees are already familiar with your project or how it solves a general problem. Talk proposals can be very specific solutions to a problem, or can be higher level project overviews for lesser known projects. Please include the following information when submitting a proposal:

• Your name
• The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects)
• Short abstract of one or two paragraphs
• Short bio (with photo)

The deadline for submissions is November 18th, 2015. FOSDEM will be held on the weekend of January 30th-31st 2016 and the SDN/NFV DevRoom will take place on Sunday, January 31st 2016. Please use the following website to submit your proposals: https://penta.fosdem.org/submission/FOSDEM16 (you do not need to create a new Pentabarf account if you already have one from past years). You can also join the devroom’s mailing list, which is the official communication channel for the DevRoom: network-devroom at lists.fosdem.org (subscription page: https://lists.fosdem.org/listinfo/network-devroom)

The Networking DevRoom 2016 Organization Team

5 Humanitarian FOSS projects

Over on opensource.com, I just posted an article on 5 humanitarian FOSS projects to watch, another instalment in the humanitarian FOSS series the site is running. The article covers worthy projects Literacy Bridge, Sahana, HOT, HRDAG and FrontlineSMS.

A few months ago, we profiled open source projects working to make the world a better place. In this new installment, we present some more humanitarian open source projects to inspire you.

Read more

What’s in a job title?

Over on Google+, Aaron Seigo in his inimitable way launched a discussion about  people who call themselves community managers.. In his words: “the “community manager” role that is increasingly common in the free software world is a fraud and a farce”. As you would expect when casting aspertions on people whose job is to talk to people in public, the post generated a great, and mostly constructive, discussion in the comments – I encourage you to go over there and read some of the highlights, including comments from Richard Esplin, my colleague Jan Wildeboer, Mark Shuttleworth, Michael Hall, Lenz Grimmer and other community luminaries. Well worth the read.

My humble observation here is that the community manager title is useful, but does not affect the person’s relationships with other community members.

First: what about alternative titles? Community liaison, evangelist, gardener, concierge, “cat herder”, ombudsman, Chief Community Officer, community engagement… all have been used as job titles to describe what is essentially the same role. And while I like the metaphors used for some of the titles like the gardener, I don’t think we do ourselves a service by using them. By using some terrible made-up titles, we deprive ourselves of the opportunity to let people know what we can do.

Job titles serve a number of roles in the industry: communicating your authority on a subject to people who have not worked with you (for example, in a panel or a job interview), and letting people know what you did in your job in short-hand. Now, tell me, does a “community ombudsman” rank higher than a “chief cat-herder”? Should I trust the opinion of a “Chief Community Officer” more than a “community gardener”? I can’t tell.

For better or worse, “Community manager” is widely used, and more or less understood. A community manager is someone who tries to keep existing community members happy and engaged, and grows the community by recruiting new members. The second order consequences of that can be varied: we can make our community happy by having better products, so some community managers focus a lot on technology (roadmaps, bug tracking, QA, documentation). Or you can make them happier by better communicating technology which is there – so other community managers concentrate on communication, blogging, Twitter, putting a public face on the development process. You can grow your community by recruiting new users and developers through promotion and outreach, or through business development.

While the role of a community manager is pretty well understood, it is a broad enough title to cover evangelist, product manager, marketing director, developer, release engineer and more.

Second: The job title will not matter inside your community. People in your company will give respect and authority according to who your boss is, perhaps, but people in the community will very quickly pigeon-hole you – are you doing good work and removing roadblocks, or are you a corporate mouthpiece, there to explain why unpopular decisions over which you had no control are actually good for the community? Sometimes you need to be both, but whatever you are predominantly, your community will see through it and categorize you appropriately.

What matters to me is that I am working with and in a community, working toward a vision I believe in, and enabling that community to be a nice place to work in where great things happen. Once I’m checking all those boxes, I really don’t care what my job title is, and I don’t think fellow community members and colleagues do either. My vision of community managers is that they are people who make the lives of community members (regardless of employers) a little better every day, often in ways that are invisible, and as long as you’re doing that, I don’t care what’s on your business card.

Project naming

Number two in an occasional series of “time I wish I could have back” topics related to releasing proprietary software projects as free software.

What’s in a name?

It was famously said that there are 2 hard problems in computer programming: Cache invalidation, naming things, and off by one errors.

Naming a project is a pain. Everyone has their favourite, everyone’s an expert, and there are a dozen different creative processes that people will suggest. Also, project names are subject to approval by legal and brand departments often, which are 2 departments most engineers don’t want anything to do with. So how do you come up with an acceptable name without spending weeks talking about it? Here are some guidelines.

Avoid anything related to the company name or products

You don’t want to have corporate trademark guidelines, certification programmes, etc impacting the way your community can use the project name, and avoiding names related to company assets will make it easier to transfer trademark ownership to an independent non-profit, should you decide to do that in the future. In terms of maintaining a clear separation in people’s minds between the community project and your company’s products, it’s also a good idea to avoid “line extension” by reusing a product name

Outside of that, the number one thing to remember is:

Projects names are not the most important thing about your project

What’s important is what problems you solve, and how well you solve them. The name will grow on people if they’re using the project regularly. You can even end up with interesting discussions like “is it pronounced Lee-nooks or Lie-nucks?” which can galvanise a nascent community. Also, remember that:

Project names can be changed

How many projects fall foul of existing trademarks, end up rebranding soon after launch, or are forced to change names because of a change of corporate sponsor or a fork? Firefox, Jitsi, WildFly, Jenkins, LibreOffice, Joomla, Inkscape all started life under different names, and a rename has not prevented them from going on to be very successful projects. The important thing, in an open source project, is to start small so that you don’t have a huge amount invested in the old name, if circumstances require you to change it.

Avoid a few pitfalls

Avoid using anything which is related to the trademarks of competing companies or projects, unless it is pretty abstract (Avid to Diva, Mozilla to Mosaic Killer, Eclipse to Sun).

That said, don’t worry too much about trademarks. Yes, do a quick search for related projects when you have a shortlist, and check out USPTO. But just because there is a Gnome Chestnut Farms in Bend, Oregon doesn’t mean you can’t call your free software desktop environment GNOME. Domain of use is a powerful constraint, take advantage of it.

Avoid potentially politically incorrect or “bad language” words. Also, avoid artificially smart acronyms. The Flexible Add-on Release Tracker might seem like a good idea, but… don’t.  GIMP is a notable exception here to both rules, and countless days have been spent defending the choice of name over the years.

Do worry about the domain name. This will be the primary promotion mechanism. People shouldn’t spend time trying to figure out if your project is hosted at “sandbla.st” or “sandblast.org” or “ProjectSandblast.org”. Make sure you get a good domain name.

Empower a small group to choose

The decision on a name should belong to 1, 2 or 3 people. No more. Once you realise that names are not the most important thing, and that the name can be changed if you mess up badly, that frees you from getting buy-in from everyone on the development team. The “committee” should include the project leaders (the person or people who will be identified as the maintainers afterwards), and one person who is good at facilitating naming discussions (perhaps someone from your Brand department to ensure their buy-in for the result). Beyond that, do not consider surveys, general calls for names, or any other process which gives a sense of ownership of the process to more than 2 or 3 people. This way lies many weeks and months of bikeshedding arguments.

Have a process

1. Start with a concept and work from there. Break out the Thesaurus, make a list of related concepts.
2. Names can be abstract or prosaic, it doesn’t really matter. Discourse is one of the most wonderfully prosaic project names I’ve seen, but StackOverflow has nothing to do with a questions & answers forum. Ansible is a made up word, Puppet and Chef both evoke wonderfully orchestration while being dictionary words.
3. Keep the shortlist to names which are short and pronounceable in multiple languages.
4. Cull ruthlessly – don’t keep “maybe” names. If you get to the end, go back to the concepts list and start again.
5. If you get to a shortlist of 2 or 3 and can’t decide, use random() to pick the winner or go with the choice of the project leader.

In general, don’t spend too much time on it. You should be able to get a couple of candidate names in a few days of discussion, submit them to Legal for a trademark review, and spend your time on what really matters, understanding your users’ problems and solving them as well as you can.

Of course, this is easier said than done – good luck!

Choosing a license

One in a series of indeterminate length I am calling “mostly unimportant questions which take an inordinate amount of time to resolve when releasing a project as free software”. For the next topic, I’m hesitating between “naming”, “logo/icon/mascot design” and “mailing lists or forums”.

Choosing a license

Free software projects need licenses. But choosing a license is such a pain that most github projects don’t even bother (resulting in an initiative by Github to rectify this). And when taking a closed source project and making it free software, the topic of license choice will take a huge amount of time and effort.

I have found the following questions accelerate things nicely.

1. Does the project exist as part of a greater ecosystem (eg. Apache, Eclipse, GNOME, Perl, Ruby)?
2. If so, is there a predominant license in that ecosystem (eg EPL for Eclipse, MPL for Mozilla, MIT for Ruby gems, BSD for *BSD)? Then use that license.
3. Does your business model depend on you having total control of the project for the foreseeable future? (Aside: If so, consider changing your business model) Consider GPL v3+/proprietary dual license
4. Do you want to grow a vibrant developer community around your project? If not, why not? Avoid dual license, copyright assignment
5. Do you want to grow a vibrant service partner/extensions ecosystem, including proprietary extensions, around your project? Avoid GPL v2+ or v3+ – prefer MPL v2 or Apache v2
6. Do you have any dependencies whose licenses you must comply with (eg. GPL v2 hard dependency)? Ensure you can distribute result under a compliant license
7. Do you have concerns about the patent portfolios of potential project contributors? Choose from GPL v3, MPL v2, Apache v2 for stronger patent protection for contributors – avoid MIT or BSD
   
8. Do you believe that all contributors to the project, including extensions, should be subject to the same rules? Choose GPL v3
9. Do you believe that the source code is free, and people should do whatever they want with it as long as they give you credit? Choose MIT or Apache v2
10. After answering these questions, are you considering a license outside of (L)GPL v3, MPL v2, Apache v2 or MIT/BSD? Don’t.

After all of this, there are still situations which can lead to different outcomes – perhaps you want to join a specific non-profit later, and your license choice will be influenced by that. Perhaps you have a dependency currently which you plan to work around later, and you might dual license source code contributions under multiple free software licenses to allow relicensing easily (as OpenOffice.org and Mozilla have done). But the answers to the 10 questions above will at least reduce the scope of your search to one or two licenses.

Any considerations I have missed? Comments welcome!