OSCON Keynote: Distilling Distinction


Next Keynote this morning was Distilling Distinction with Robert “r0ml” Lefkowitz.

Aristotle believed that the most effective way to appeal to authority is rhetoric … but that doesn’t work so have to manufacture distinction – how do you get people to believe that you know what you’re talking about? The next thing you can do is “do” stuff … people see that you have done stuff that proves that you know what you’re talking about. For example you can go in to an interview and say I am smart and I learn stuff … or you can point people to your GitHub account and show them the code you’ve already written.

One way to prove distinction is to become a member of a professional organization and get recognized by them … but the people around us here at the conference who we know deserve recognition haven’t been recognized by these organizations so how do we become distinguished? Well if you don’t join you can’t win/be recognized. More of us in open source need to join professional organizations like ACM or IEEE and get both ourselves and our open source recognized.

OSCON Keynote: Turing’s Curse


First Keynote on the final day of OSCON was Turing’s Curse given by John Graham-Cumming (CloudFlare).

John pointed us to The Mother of All Demos he wanted to talk about the history of computers – because the new stuff isn’t really that new. Cloud computing for example there was a book about this in 1966 (I missed the title). Wifi … also not so new, it was actually used in 1971. Solid state drives … invented in 1976 (only 4MB … but still…).

I couldn’t keep up with John’s entire history lesson! I was never very good at dates and history :) But I’m sure the slides or a video will all of the dates will be online.

The moral of the story – a lot of what we have today was actually already done way before we thought so. So what’s the implication of that? While it sounds depressing that everything you’re doing has been done before, but it’s not really depressing because it shows that there is a great value in a computer science education. We’re in a great age of productivity! We should be thankful that there are all these great ideas that we can build on and make more efficient/faster and link together!

OSCONOne thing we haven’t done is conquer unreliability – software is still unreliable.

“There is no program that given a description of an arbitrary computer program can decide whether the program finishes running or continues to run forever” – 1936 – Turing’s curse.

Basically there are certain things that machines will never be able to do for us. If everything has been done before then what should we do? What we do is come up with better debuggers – work on reliability. We have to help programmers make fewer mistakes and find the mistakes they do make. John would like us to invent this before Episode 7 of Star Wars comes out!

Home Automation with Arduino/RaspberryPi


Up last today was Rupa Dachere (CodeChix) talking about Home Automation with Arduino/RaspberryPi. The session ran over and started late so I only get to share a bit of info with you – you can probably find slides online somewhere.

Rupa decided to start this project so that she could find out who was at her front door, when they got there (time/day) and wanted to be notified that they have arrived in a timely fashion (seconds). For example Contractors had promised to be there at a time and she didn’t think they had arrived – she wanted proof that they never came by.

Phase one of this project was having a snapshot of the visitor and having it sent via text to the phone, then a video sent to the phone was phase 2, followed by a video live stream and audio notification in phase 3. Today we will hopefully get a demo of phase 2.

This solution was picked because it’s reasonably inexpensive (around $100). There are no commercial products that did what she wanted and if they got close they were too expensive.

The hardware needed:

  • Webcam
  • Adruino (Uno R3)
  • Rasberry Pi
  • Proximity sensor (HC-SR04)
  • independent power for the pi and arduino

The software was written using Python (on GitHub).

OSCON: Everything Counts


Next up was Everything Counts with Mari Huertas (Obama for America).

To help all of your work count Mari breaks things down in to three things:


If you lead with design and shape your project. Mari shared the following quote: “Good design used to make you stand out on the web. Now it’s the price of entry” – Ev Williams. You want to prototype, prototype, prototype!! Along those lines Mari shared a quote from Mike Sellers

An idea is not a design
A design is not a prototype
A prototype is not a program
A program is not a product
A product is not a business
A business is not profits
Profits are not an exit
And an exit is not happiness.

Learn who’s voices really matter and listen. This doesn’t mean you blow off people, it means you just want to stay on task.

Remember your objective. Tech is cool, but you don’t want to use it just for the sake of using it – you want it to help with your objective.

Next, define your deployable – you don’t want to save this until the last stage.

Make your staffing plan clear and post it publicly – try RACI Charts for this. Also make sure that you organize your staff so that people who have issues with each other aren’t on the same teams.

Most importantly (in my opinion) build your QA plan while you shape your product! Usually people wait until the end for this and it causes you to miss things and waste time at the end on finding issues.


This is not only done by the project manager! Make sure that your processes are as simple as possible. Get out the way of the work so people can do the work. You also want to recognize and respect preferred channels for communication. Each group might have a different preference. Some people like GitHub, others like BaseCamp, let them use what they want as long as it’s working. If it’s not working then you want to jump in and find a new tool.

You need to communicate issues with people. Don’t just keep people in the dark if something isn’t working. Just tell people that it’s broken and you’re working on it – people appreciate this (that’s how we handle support at work). There is no room for pride or fear here – don’t keep it to yourself because you can’t admit that you made a mistake or that something is not the way it should be. And if you’re the manager of the project make sure that your team knows that this is okay – put it out there and tell the team that you’d rather know that there’s a problem when it happens.

Make sure when you’re communicating that you speak plainly, openly, frequently and briefly. Put your documentation somewhere public.


Build fast, but build smart. Do code reviews and talk about why you’re building the way you are. Also document document document!! And document along the way instead of after. If you wait until the end then you have to remember why you made the decision you did.

Final Thoughts

“Default to calm.” When you’re working with a team it’s on you to bring your best self to the table. It sets the tone for the entire project. No one wants to work with people who are freaking out. Make sure you have fun – Mari was in a high stress situation but they still made time for fun. Remember you’re all people trying to do great things and do your best work.

Keep in mind that there are different techniques for working with groups that are all in the same place or distributed (virtual). At ByWater we use IRC all day, but that might not work for you so you have to organize your time/day according to the people you work with. Make sure that you learn (just like in person) the ways people like to be contacted/dealt with.

Remember that Everything Counts! Mari can be reached @marihuertas.

Bookmarks for July 25, 2013

Today I found the following resources and bookmarked them on Delicious.

Digest powered by RSS Digest

Literacy: The Shift From Reading to Writing


Next was Literacy: The Shift From Reading to Writing presented by Robert Lefkowitz. I missed the very beginning cause I ended up in a talk about JavaScript … not that it wouldn’t have been a good talk … just not for me ;)

So let’s start with what I heard on the way in … code is written to be read! So you need to make sure that your code is readable. Robert talked about ‘Literacy and Learning’ by Deborah Brandt in which the author talked about the origin of literacy and why literacy was important. Reading was important to be able to read the word of God and/or participate in government, but writing was scary. For example in 1853 it became illegal to teach slaves to write because this could be dangerous. At that time they were allowed to read because they needed to learn the word of God – of course that changed later on when it became illegal for them to read and/or write.

So the four ages of literacy are:

  • No readers, no writers (thru Socrates)
  • Few reader, few writers (Plato thru Gutenberg)
  • Many reader, few writers (Gutenberg thru Tomlinson/Ayyadurai/Winer/Hillebrand/Jobs/Zuckerberg/Dorsey)
  • Many reader, many writers (post-Jobs)

So now the way we’re reading has changed! But we’re writing more than we ever did in the past.

Shortly after the introduction of writing, craft literacy came on the scene – people writing about their craft. Today we have programmers writing and then the end user coming in and adding little mods/edits etc. “Recent studies reveal that an important aspect of end user computing is the emergence of programming communities of cooperating users that develop e when a program is used by a group of people.”

In programming we have a few number of writers (programmers) to readers (users) – but that’s changing. More and more people are copying from others and piecing things together – but what most people argue is that it’s better to write your own cause then you not only create but you learn. I’d argue that copying can also help you learn – as long as what you’re copying is written right and well.

I’m not sure that I caught everything that Robert talked about because I was tracking down the resources and big words he was using :) but hopefully this is a clear enough summary for you all.

“Good Enough” is Good Enough!


First session this morning was “Good Enough” is Good Enough! with Alex Martelli. I can’t possibly to Alex justice in my notes below because he was an awesome and charismatic speaker, but I’ll try!

Alex started by asking us if we should always strive for perfection and anything less is unacceptable. No one raised their hands. Instead we agreed that we should release early and release often and constantly fix and improve things.

There are 3 goals that are important to both approaches:

  • simplicity
  • correctness
  • consistency
  • completeness

However they take different priority in the two approaches (“worse is better” and “right thing” coined by Richard Gabriel in 1989).

In the “worse is better” approach takes advantage of incremental development versus the ‘right thing’ approach that lets the experts do their thing all the way to the end before the users get their hands on it.

These models kind of match up with Eric Raymond’s comparison of the ‘cathedral’ (“the right thing”) to the ‘bazaar’ (“worse is better”).

If you only want to release perfection then you have to have designed everything up font … and that’s just not feasible in the real world. It would take forever and ever to do this! And the stakeholders resent the “forever” part of this.

In the real world requirements change all the time and the design will vary based on the implementation and bugs are only found when the software is used. So the iterative approach is the only real world option. Good enough is only good enough if you can make it better later. This means that backward incompatibility is your friend. You don’t want to keep errors and that’s what happens with backwards compatibility.

When thinking of “perfect” think of the verb – you want to perfect your work. Perfection of the product is not an achievable state. To do this you want to use a light-weight and agile process. Revision control, code reviews and testing all need to be part of the process! Code reviews are the single best technique in perfecting your code. You also have to keep documentation up to date – if you don’t document what this code is supposed to do then how does it help the poor user – users are not mind-readers.

Given the above there is one thing you don’t want to skimp on … security! This is one thing you need in from the start – it’s nearly impossible to retrofit this in to the system.

When it comes to working on bugs you want to focus all of your energies on bugs that lead to irrecoverable losses. You want to make sure you release your code without these kinds of bugs though if you can. These kinds of bugs can lead to reputation losses that might not be recoverable. More often than not though these kinds of losses – as long as you fix them in a timely fashion and in a helpful way (good service is the be all and end all of a successful enterprise) – don’t usually ruin your reputation. “Customers with the highest levels of satisfaction are not those who have never had a problem, they are the ones who did have a problem and had it speedily and courteously fixed.” (the Service Recovery Paradox). We rarely think of service in an open source context – but we should!

This theory applies when talking about finding employees as well. You want the “perfect” employee – that takes forever. Pick someone who’s personality and culture matches – who’s keen to learn and knows some of what you need. This person will then improve over time with your company/code.

In conclusion we are not talking about lowering our exceptions – our dreams must be big!! The best way to change the world though is to release early, release often! We need to reach beyond ourselves and release incrementally. “Less is more!”

Check out the slides from more info!

Keynote: We The People: Open Source, Open Data


Up last this morning was Leigh Heyman (Executive Office of the President) in a talk titled We The People: Open Source, Open Data. We The People is the White House’s online petition platform. Online petitions are not particularly new, but there hasn’t been much change in the way they’re handled. The goal of We The People is to change that – President Obama said that he wanted to have the most transparent and open administration in history – and so We The People was born. Leigh pointed us to the White House Death Star petition and to show that the administration was going to stand by their promise they responded to this petition because it met the threshold.

When talking about open source specifically though you can go look at Whitehouse.gov/developers. So what’s next?? APIs for Whitehouse.gov and We The People. A hackathon was held at the White House to create more APIs.

What comes next is up to us here at OSCON. We need to go fork the White House code on GitHub and participate!

Keynote: Licensing Models and Building an Open Source Community


Next was Licensing Models and Building an Open Source Community presented by Eileen Evans at HP. Eileen made a broad generalization about open source licenses – there are two types of licenses: Permissive and copyleft. The question is can a permissive license be used to build an open source community. Originally Eileen felt that the answer was “no”. You needed a contractual reason to make people contribute back to open source. Today though more projects seem to be leaning toward permissive licenses. And so, based on the data, the answer is “yes” a permissive license can be used to create a vibrant open source community.