Sugar (the software on OLPC) and my conversation with Walter Bender

I had a good conversation with Walter Bender, former president of One Laptop per Child (OLPC) and the founder of Sugar Labs. Sugar is the software that comes on OLPCs. It also comes in some of the Linux distributions like Debian, Ubuntu and Fedora and can run on most laptops.

Walter is interested in how Sugar Labs can make Sugar successful. He wants to make Sugar successful because Sugar helps computers be effective in education by providing a user interface for kids that promotes "sharing, collaborative learning, and reflection." It’s currently used by half a million kids world-wide through OLPCs but there are a lot more kids out there.

I think the huge advantage that Sugar has is that is a very noble project with noble goals. How can you not get people excited about helping kids learn? The challenge they have is reaching the right groups. The three groups they need to reach are:

  1. Developers. Sugar still has a lot of things that need to be developed or changed. Like any software project, it’s an ongoing process. (And I know my mother-in-law, Anita, has a list of features she’d like to see!) I think this group is out there and willing. If you have a good cause, there are some very good developers out there that have shown they’re willing to give time and energy to making good things happen.
  2. Upstream. There are parts of Sugar – or rather lots of things that have been developed by and for Sugar developers – that probably belong upstream in either GNOME (GTK) or the Linux distributions. I think these groups are very open to discussion and doing what makes sense. (I offered to facilitate any introductions or conversations that need to happen, if they aren’t happening already.)
  3. The outreach community. I could have called this "teachers and kids" but I think it’s bigger than that. I think there’s a whole community of people out there (like my parents, almost-retired teachers) that would love to help schools get started with computers. There are also groups out there refurbishing computers that would love to get them to the schools that need them. This is where the key work has to be done. My dad has said he’d be more than happy to help but someone needs to show him (and people like him) how the software works and then connect him to the schools that need help. And make sure those schools have hardware. (I wanted to create a sister school program between my stepson’s school and a school in Mexico, buy OLPC for all, set them up and have them become email buddies. Dad was going to do the Mexico part, I was going to do the fund-raising and Colorado parts. But then OLPC had supply chain problems and then I got a new job.) I imagine user groups and conferences of people willing to volunteer or take volunteer vacations to educate local schools and schools in developing countries how best to use the software in classrooms.

The other thing Walter and I talked about funding. I really encouraged him to do a donations program like FSF’s associate members or Friends of GNOME. I think you could get people to give to a cause like kids in education. And then use the money to fly developers to conferences, teachers to conferences and schools that need them to get things rolling, maybe hardware or funding for some of the recycling efforts, etc.

But by far I think his biggest challenge will be reaching the people that can help him do the outreach effectively.

7 of the most common open source myths

Here are some of the misunderstandings around open source software that I hear every day.  Feel free to add your own!

  • The most important thing is whether you modify the code or not.
    I keep hearing from people, “we’re ok because we didn’t modify it.”  Or they create a policy that doesn’t allow anyone to modify open source code because then they think they are risk free.  I agree, modifying open source software may cause a support problem, but it isn’t what triggers anything special in the license.  The GPL says that if you make modifications to the software, you have to distribute those modified source code files with your binaries.  But it is the distribution that triggers that clause, not the modification.  So if you distributed the binaries unmodified, you’d have to distribute the source code.  And if you linked statically to those GPLed binaries, you’d have to distribute your source code as well.  But only if you distributed your product.  If you are using it in house, it really doesn’t matter whether you modified it or not.  Except from a support perspective.
  • If you modify GPL code, you have to give the modifications back to the project.
    I highly recommend you do give your modifications back – it’s the nice, neighborly thing to do.  It also makes your life easier to be using the standard version and not your own forked version.  However, you don’t have to give those modifications back.  You only have to give the
    modified source code to anyone you give the binaries too.  Now note that they can give that modified source code to anyone they want, which brings me to the next point.
  • Distributing GPL code under an NDA does not count as distribution.
    I’m not an attorney, and it hasn’t been taken to court yet, but I think most attorneys would agree with me that distributing GPL code under an NDA not only counts as distribution but the recipient can give that GPL product to anyone they want to under the terms of the NDA regardless of what your NDA says.  It’s not a risk I would take.
  • If you are only using open source software internally, you don’t have to worry.
    First I’d argue that nothing used internally stays internal – what if you share with a partner or sell a group to another company or … That said, many licenses have clauses that trigger on something other than distribution.  Sometimes they are simple, sometimes they aren’t.  For example, one says that you have to buy a copy of the book for every developer on the team. Regardless of whether you redistribute or not.
  • Anybody can sue me for using open source wrongly.
    Only the person that owns the copyright for a piece of software can sue you for violating the license.  Typically, the person that owns the copyright is the person that wrote the code.  They can however give that copyright away.  They can even give it away and keep it for themselves so that two people hold the copyright.  The copyright holder is also the only person that can change the license on a piece of software.  (Note that this is why SCO lost – in the end the court ruled that SCO didn’t hold the Unix copyright.)
  • There is no support for open source. First off, lots and lots of products are open source.  The support options vary widely from the do it yourself variety to multiple companies competing for your business.  The problem is you have to do a lot of research – the products’ name doesn’t give you a direct clue to the company that supports it.  And you might come up with more than one name and have to compare several companies.  But there are lots of people and companies out there supporting open source software.
  • Freeware and Shareware are open source. Freeware and shareware are not open source.  All things free are not open source.  Just because it’s free, doesn’t mean it’s open source.  The freeware and shareware licenses are very different and do not meet any of the traditional open source guidelines like providing source code, allowing modification and redistribution.

Got any others?

Books about open source software

I often get asked to recommend reading on open source software so I thought I'd share with everyone.

Here are the two staples I recommend to everyone:

Then, depending on who was asking and what they were looking for, I might also recommend:

  • The Business and Economics of Linux and Open Source
    by Martin Fink. This book does a good job of explaining why and how
    open source software can be useful in an enterprise. How does the new
    model fit into business?
  • Succeeding with Open Source
    by Bernard Golden. If Martin Fink's book is the why open source fits
    into business, Bernard Golden's book is the how. It goes over the ROI
    of using open source software and describes a selection and evaluation
    process in detail.

Then there's two books that I haven't read yet but are high on my
list and come highly recommended by others. (I actually own copies of
them which shows my good intentions!)

  • Open Sources 2.
    This is a sequel to Open Sources and contains essays by some of the
    newer people in the field and people that I think of more as enablers
    and business people – the people bringing open source to businesses –
    than the people that created the actual open source software.
  • The Success of Open Source by Steven Weber. I've been told that this book does an excellent job of explaining the open source movement at a broad level.

So there you go. In case you didn't have anything to read over your
holidays, now you've got a whole list on one of my favorite topics!