Keynote: Diversity in the Innovation Economy

OSCON

First up this morning was Laura Weidman Powers from Code2040 in a talk entitled Diversity in the Innovation Economy: Why It Matters And What You Can Do About It.

Laura started by talking about race (which is “super awkward” according to her). Even though is awkward for her she thinks it’s important for us to talk about. Two things are happening in America that make it important. First the software world is easting the world – it’s the key component in nearly every industry. The second is a massive demographic shift where by 2040 42% of the population will be Black or Latino.

Diversity in TechThis matters because if we look at the graph here we see that Blacks and Latinos are not filling rolls at the top of tech jobs. This matters to this audience because we’re a community and communities care about the people in them. In 2012 Laura’s team started 2040 because they cared about this issue. This organization brings high performing young Latino and Black software developers in to internships with top tech companies.

One of the 2040 students said: “Diversity isn’t the problem here, diversity is the opportunity.” So let’s see this as an opportunity to live up to our potential of universal access. We can draw more talent in to the tech sector by creating pathways for a more diverse audience to join and succeed in our industry.

Code2040 shows kids what they need to know about getting in to the tech industry – simple things like a GitHub account and an online portfolio. But what can we do? We can get involved in Code2040.

How To Get More Kids To Code

OSCON

Next up was How To Get More Kids To Code with Regina ten Bruggencate and Kim Spiritus. I got in late (I was waiting in line to get a free signed copy of ‘The Art of Community‘ by Jono Bacon) so I missed the beginning of this session, but came in as they were demoing Scratch. This is a website where kids can play little games (available in 40 languages) and then click the ‘See inside’ button to see the code behind the game in a kid friendly way. It’s a great way to get kids to see code and learn not just programming, but the concepts of open source.

Next up was Alice meant for kids ages 8 and up. This site uses a story telling type of learning to program. For some reason boys don’t seem to like Alice very much (they’re not really sure why since the kids can use aliens and spaceships in their stories). Using Alice you can drag and drop objects in to your scene/story and when you do it pops up windows where you enter properties for the items. Once you have your scene set up you can edit the code by clicking on the object (your alien for example), but the edit screen is not your standard ‘code’ view, instead it’s friendly to kids by giving them pull down menus of actions.

Greenfoot is meant for slightly old kids (12+), but works similarly to Alice. The code editor in this shows you the Java with a bit of color coding (unlike the other tools that showed code in easy to use bubbles). Greenfoot is actually just a visual interface on top of BlueJ.

Another option is to use Mindstorms which walks kids through creating a robot and programming the “brain”. Mindstorms is great for kids age 8 and up.

Sagan is an open source project where you can simulate the Mars rover. It comes with 3 Mars landscapes and you program your rover to move around. It even has conversion tools so you can load it in to a Mindstorms robot (and others).

Arduino is a great way to teach kids about programming and electronics (it’s not only for kids!).

Raspberry Pi is a computer with a flash hard drive that will take any Linux distribution. I has 2 USB ports (keyboard and mouse), an ethernet port, and a port to connect to your TV. This is a great way to let the kids see the inside of the computer and work with it and programming on it. Quite a few people actually use this as a media center.

In addition to tools, there are events out there for kids. Devoxx 4 Kids is a one day convention with a keynote in the morning and parallel tracks during the day. In the sessions they learn about all of the tools listed above. The speakers are all computer professionals like us who want to get the kids involved. The first one in the Netherlands was sold out in 2 hours!!

Another initiative is the First Lego League which is a robotics project for kids. The kids have to create a Lego Mindstorms robot from scratch and then they have to share their solutions with the other teams (so a very open environment). There are competitions as well, but teams are not required to compete.

Maker Faire happens all around the world where kids can share what they have created – a place to share your love of science and building things.

VHTO is a program for girls in the Netherlands where kids can participate in different types of programs like Talent Watcher where they get to find where their talents lie. They also have a program called Mirror Image which shows them women in technical fields that they could participate in. Another program they offer is Speeddating where they get to decide if they want to go in to a more technical field than most girls might choose. They also have Girlsday where companies say that X number of girls can come visit us and see what it’s like to be in this field.

Non-Profit Organizations for FLOSS Projects

OSCON

We had several speakers talking to us about Non-Profit Organizations for FLOSS Projects: There Is No Place Like Home.

First up was Software in the Public Interest (SPI). SPI was founded in 1997 as a “fork” of the Open Source Institute. SPI provides a bank account, the ability to receive charitable donations, ability to sign contracts, and some light legal assistance. They do not have any part in your project governance, so they are simply a fiscal sponsor/non profit organization.

You join SPI because you need a bank account or what to run a fundraising campaign you have an NGO in another country and you don’t want change your project to join a non profit.

Next up, Software Freedom Conservancy who’s key difference from SPI in that they are a ‘Direct Project” fiscal sponsor. This means that your project becomes part of the Conservancy. In a legal sense Conservancy can act officially in the name of the project as a corporate entity. This gives you liability protection. Like SPI they also offer directed donations. Unlike SPI they offer more legal assistance, conference organization assistance, fundraising services and asset management. A full list is here: sfconservancy.org/member/services.

The Apache Software Foundation is more like a family than the above two (says the speaker). It was started to provide indemnity, infrastructure and independence to those who joined the family. All the projects do have to have the Apache license (whereas the other two want any OSI approved license), a collaborative consensus-driven development style and a diverse community (at least 3 independent contributors) to join.

Eclipse which is a 501(c)6 or Trade Association unlike the three above who were 501(c)3. Eclipse offers infrastructure, intellectual property (IP) management, development processes that the members are expected to follow and community development marketing people who help develop communities around projects. Eclipse is technology and forge agnostic and are flexible on the licensing of the software (it used to be just EPL).

Outercurve Foundation was up next. They too are a 501(c)6 like Eclipse. The goal of Outercurve is to help open source projects be successful by offering legal structure, business operations and technical services. One of the best ways they can help is to get contributions to their projects. Like many of the others listed here they are agnostic on license, development process and language the software is written in. That said they do require that their members have a development process in place and have a published governance.

Finally, The Linux Foundation is another 501(c)6. Jim Zemlin spoke more about the importance of these organizations than what the foundation offers. These organizations provide you with the structure you need to grow your projects – and that’s what really matters.

Collaborative Teaching for More Effective Learning

OSCON

Brent Beer from GitHub talked to us after lunch about Collaborative Teaching for More Effective Learning. As we know budgets are shrinking – everywhere – but in particular in education. So what are we doing in schools to get more bang for our buck? One option is to start using open source software to lower overhead costs. There are also tools out there that are specific for schools with shrinking budgets. GitHub has accounts for schools for example.

More importantly, how do we collaborate and communicate effectively with students – specifically in our computer programming classes? There are tools like Moodle and Blackboard in schools, but they aren’t really terrible friendly to educators who might want to set them up. So you need to hire people or a company to help you set up and maintain the system. That requires money which you might not have. Also, even though those tools have communication areas they’re separate from the assignments. We need one place to go where all the assignments and the communication can happen.

Specifically for these computer programming classes, GitHub allows you to have your code in your repository and then allow communication right there through comments. It also facilitates collaboration and introduces students to open source development by having their repository open to their entire class.

GitHub would also be great for keeping your notes and programs for classes organized as a teacher. This way you can track changes to your own work, share work with other teachers, and get comments and collaboration from other instructors who might know how to solve the problem you’re sharing more efficiently or differently. You could also use GitHub as a social network to find other teachers who are out there teaching the same things.

One example of a school doing this Tufts.

To learn more about GitHub go to youtube.com/githubguides and for the slides visit http://bit.ly/oscon-ghteaching.

Using Open Source in the Classroom Every Single Day

OSCON

Jon Roberts of the Davis School District in Utah talked to us about Using Open Source in the Classroom Every Single Day. He used to be a hacker and now he’s a teacher. Kids today expect constant connectivity and Jon wanted to talk to us about how he works with kids like this. Before becoming a teacher, Jon worked in software development for the military and moved on to becoming an independent open source contractor. The school Jon works for is a special school for children who don’t always want to learn – the “trouble” students. The classes are small so that they can give individual attention and can use creative approaches to teaching.

Why teach open source in the classroom?

  • Technology has an increased role in education (there is a new curriculum required for match)
  • Open source is free as in speech (communication is key)
  • growing footprint for open source in the working world
  • inherent sense of contribute and community
  • obviously and especially useful for computer programming (which Jon also teaches)

There are some obstacles though:

  • State office of education has guidelines for the curriculum that require things like teaching MS Office
  • District purchasing office wants a ‘throat to choke’ they want a place to go to complain – they are not as comfortable with the open source model
  • School admins have a fear of the unknown
  • Technical support staff doesn’t want unwanted responsibility (aka they don’t want to learn something new)
  • Students prefer what they already know (they have MS at home probably) – this is where he gets the least resistance though

Jon’s students see the KDE desktop in every class he teaches so they’re used to seeing Linux over MS Windows.

Jon has made teaching open source a viable option in the sight of these obstacles by focusing on curriculum goals and objectives. He also uses older computers and personal resources so that he’s not using new systems that he has to get approval for from purchasing departments. He also follows my favorite motto – it’s easier to ask for forgiveness than permission. So instead of asking for approval he just does it and then the administration finds it hard to break it all down. Another little step he takes is to keep his computers off the network so that the tech people don’t see the machines that they don’t want to support showing up. Finally – and most importantly – he enlists the students support in making the case for open source. The kids want to learn how to develop for things like Android so get their support.

Some examples of open source he uses to teach include Perl scripts to run time tests. He also walks students through the installation procedure so that they can take what they learn and repeat it at home. Jon does something I do a lot – he created presentation and video tutorials so that students can see lectures again or review content they may have missed. He also has a lot of applications to assist in teaching his math lessons (some available from KDE Education Project).

10 Secrets to Sustainable Open Source Communities

OSCON

Elizabeth Leddy gave the next talk I attended entitled: Wish I Knew How to Quit You: 10 Secrets to Sustainable Open Source Communities. Elizabeth works with Plone but wasn’t really involved in open source until about 5 years ago. With open source we often start by working at a company that supports a specific open source application and there are two paths we can take. One path is that you start to get annoyed with the way things are going and so you jump to another open source project. Or you can get involved in the open source community so thoroughly that you can move from one related company to another (this is what I have been doing with Koha so I totally understand this path).

The goal of Elizabeth’s talk was to make sure we all create loving communities like the one around Plone. When picking your community you should think about what you want to get out of it and what you want to contribute. Open source isn’t just about code. The people in your open source community (if you’re like Elizabeth or me) are the first people you say good morning to – you wake up and get on IRC and say hi to your family. Elizabeth said that she sometimes wakes up and feels like she has 400 brothers … I totally agree … but I’d change that to ‘siblings’ :)

#1 Make Plans

When developing your community you have to make it clear that you’re in it for the long term. You need a plan for marketing, legal issues, documentation code cleanup – and much more!

One problem communities have is that they hold one person or a few people up as the experts in the community and the fact is that they might one day go away so you need to create a leadership pipeline (something I think Koha is good at). In addition to the fact that these people might go away – you really want to help new blood jump in to leadership roles. Also you don’t want to burn people out! You need spread the wealth.

#2 Break Plans

In addition to creating plans, you have to break plans! Don’t get so stuck on your plan that you don’t embrace change.

Make sure you keep metrics to see what’s going on in the community. Bad sentiment is hard to combat. Counter attack that by measuring community success like you would performance and share that info (I think of Chris Cormack’s Koha stats sharing with each release).

#3 Think Globally / Act Locally

Remember that there is going to be a language barrier! Many people to speak English, but they don’t “prefer” it. This means that people might take longer to reply on a mailing list because they’re translating and trying to decipher what’s being said. It also means that tone in things like flame wars might get lost on these community members.

One way to handle this is to provide multiple language channels – on IRC, mailing lists, websites etc. Also you can encourage local symposia so that people can learn about the software in their area and don’t have to try and travel.

At the very least make sure that your ‘how to contribute’ documentation is translated into several languages! That way people around the world can contribute to your project in the way you want.

Diversity isn’t just about accepting women! It’s about accepting people of different nationalities, sexualities, backgrounds, companies, etc etc.

#4 Communicate

Offer to mentor new people. Always give feedback instead of just replying with +1! Ask your community members for code reviews so that you can get better – and if others ask for reviews help them – in the end you all make the product better. Remember to thank people – especially the people behind the scenes who are doing things like managing your domain name or hosting your mailing list.

#5 Culture

We have to think about culture. “Culture is best perpetuated in person” … but most open source happens online. So coming up with as many ways to meet in person can really help your communication and community growth.

Remember to be transparent. Work in groups on new developments so that here is more trust. Nothing can be implied or assumed – you have to share everything out in the open so that the community knows what’s going on. You can also find people who have maybe disappeared and reach out and ask them what’s going on – it might be as simple as life has gotten hard for them and they’ll appreciate the support – even if it’s just beer delivered to their doorstep.

In person meetings shouldn’t focus just on code – more importantly we want to educate the new people, we want to hash out the problems while you’re in person. Getting people to participate is more important than fostering observers … if the focus of an in person meet up is on producing code you might end up with this.

#6 Stop Recruiting Developers

There is a lot of stuff that has to get done in a long term project that does not include code. Things like marketing, business, documentation, legal and fiscal issues. For Koha all the documentation for users was written by librarians (not developers).

#7 Redefine “Participate”

Make sure it’s not just development

#8 Governance

Think twice before contributing to a project without non-profit foundation. Koha has seen this problem … but at the same time I’m not a fan of absolutes (never/always) so I of course contribute to Koha and always will even while we figure out the legal issues that a foundation could help us with.

Foundations can also help with conference planning, fundraising, infrastructure – they don’t have to have any say in the technical decisions if you don’t wan them to.

#9 Lose Control

Have diverse, self policing redundant teams. Other projects do have tight control and work just fine, but having groups means that one person can drop out and you don’t end up scrambling to fill the spot.

#10 Be Awesome / Expect Awesome

You’re responsible for the energy you bring into the room! The tone of your voice and how you treat people will effect everyone in the community. Thank you Koha family for having an awesome energy and welcoming all new community members!!

OSCON Keynote: Redefining What’s Possible On Mobile and Cloud

OSCON

And the final keynote Mark Shuttleworth from Ubuntu. This conference is Mark’s favorite because “The people in the open source community have extremely generous hearts.” The truly amazing thing about open source tools is that they end up getting used for things that the original developers never considered. Mark called open source tools the “tools of opportunity” which is a great way to think about open source.

Mark showed us a model of the Ubuntu Edge (check it out on indiegogo), which has the goal of having enough power to give you the desktop experience in your hand. One thing that mark talked about that is great (the other devices that will rename nameless have failed to do) is the fact that the devices need different, but yet familiar interfaces. You want to have an operating system that’s the same, but optimized for the device you’re using it on.

Mark also showed us JujuCharms which he talked about as a replacement for the white board, but it’s so much more than that. From the website:

With Juju you can begin deploying services and building relations immediately. Just find a charm and add it to your canvas to get your environment started. It’s that simple.

OSCON Keynote: inBloom Vision and Impact on Education

OSCON

Up next was Sharren Bates from inBloom, a not for profit interoperability company that works with schools in the US. inBloom is getting in to open source to enable the sharing of data between all systems in schools – they’re not there yet – but they’re nearly there. This will get inBloom a lot of things (enthusiasm, expertise and more from community members) and it will let them share a lot of things (their knowledge of schools, education, etc).

I think this particular project is on that libraries need to make note of – especially open source library systems.

OSCON Keynote: Open Source: The Secret Ingredient

OSCON

Todd Greene from Media Temple was up next.

He started talking about Linux – how it’s 1 platform with 6 different interpretations. Todd used the example of the ‘omelet’ in this comparison. The secret ingredient in omelet making – in open source software – is YOU.

MT came up with a set of values to making open source successful:

  • work with extraordinary people

  • get things done
  • always been curious
  • enjoy the journey

OSCON Keynote: The Joy of Flying Robots with Clojure

OSCON

For our next speaker, Carin Meier, we were asked to turn off our devices so that we could watch demos of clojure controlled robots. We watched Carin control her roomba and her drone from her computer – even making the two “friends” with each other.

Since I couldn’t live blog cause my computer had to be off, you can watch the video here: