As many of you know I’m fascinated not only with how the open source software model works but how companies are unintentionally influencing the model by injecting money. I’ve shared my research and thoughts in my “Would you do it again for free?” talk.
So when I saw Volunteer staff are surprisingly committed, I was not surprised to see that volunteers were more committed on average than paid staff. I was surprised to see that the study authors decided that it:
could have to do with the fact the volunteers
tended to be older. “Older people are motivated to volunteer because of
their wish to fulfil an obligation or commitment to society,”
They forgot a few things like:
- Were the paid staff volunteers before they got paid? Or were they recruited to the organization with a paycheck?
- Do the volunteers get more (or less) say in what they work on?
- Are the work conditions and hours the same for volunteers and paid staff?
- Do they do the same types of tasks?
…and so on. I would bet that not all of the paid staff were volunteers first, and that while volunteers are drawn to an organization because they believe in the cause, paid staff are drawn because of the cause and the paycheck. Some might do it more for the cause and others more for the paycheck, but it’s not so clearly for the cause like the volunteers.
(Disclaimer: I was not intrigued enough to pay $28 to read the original article, so I just read summaries and abstracts.)
In his LinuxWorld keynote, Bob Sutor said that open source hasn’t really reached the enterprise application space yet.
I used to say that the top of the stack was proprietary and that open source enters into a space as it becomes commoditized. That was 2001.
Now it’s 2008 and it’s time for open source software to lead.
The community is big enough, vibrant enough, active enough, smart enough to really lead the way in innovating new products, not just creating open source solutions that are equivalent to proprietary ones. I’d argue that this is already being done in spaces like subnotebooks – the Linux ones boot much faster than the Windows ones.
So the question is, not when will open source be in the enterprise application space, but what open source applications will appear that the enterprise doesn’t have a solution for yet?
I gave a talk at LinuxWorld called "Avoiding Open Source Lawsuits: Five Steps to Effective Open Source Governance in the Enterprise." I suppose it wasn’t the wisest title since my point was to dispell FUD (fear, uncertainty and doubt) not create FUD. (I borrowed the title (and a few slides) from an OpenLogic webinar, although my talk was substantially different.)
The point of my talk was that although I think there’s very little chance you’ll get sued for using open source software, if you (or your manager) are worried about it, there’s a few things you can do to dispell those fears. (My goal is to convince more people to use open source software by dispelling myths and giving people tools to convince the opposition.) By having clear policies and processes for dealing with open source software, a company can ensure that not only will they not be doing anything they could be sued for, but if they are sued (or just approached by someone like the SFLC), they can show them that they were doing their best to comply with open source licenses. If you show you are doing the right thing, open source developers and those that represent them are more likely to help you straighten things out than they are to sue you. Open source software developers in general want their software to be used!
So what should you do?
- Find out what open source software you are using. For this I recommend OSSDiscovery. (And once you’re done, go ahead and submit it to the Open Source Census to help spread the word about how much open source software is being used.) But whether you use the tools are not, you should keep track of what you are using.
- Establish a clear open source policy. This should include not only guidelines for how your company should use open source software but also training so that developers can evaluate licenses and know when to get help. (For help with this see FOSSBazaar.org.)
- Set up a review board. There are always exceptions, new licenses, different ways of using open source software and your employees should have access to experts to help them make an educated decision as a company.
- Make sure you are complying with the licenses you are using. To me, the hardest part of complying with open source software licenses is knowing what licenses you are using. Sometimes projects contain lots of different licenses or the project you want to use depends on a number of other projects, all with their own license. Tools like Fossology and OpenLogic’s OLEX can help determine which licenses you are using.
- Track and audit. Show that you are tracking what open source software you are using and periodically auditing it and I am sure that if you are apporached by the FSF or SFLC, that they will be more than happy to work with you.
The SFLC is not suing to make money for the BusyBox developers – they are suing to make sure that people are using GPL licensed software appropriately. I did mention a few lawsuits in my talk but it wasn’t to point out how much money people were making (I’m not sure anyone has made any money off suing for misbehavior around open source software) but rather to give specific examples of what could happen. All too often I think people don’t use open source software because they are afraid of "being sued" and they aren’t even really sure what they could be sued for.
To make a long story short, I think there’s little chance that a company that is trying to do the right thing will get sued for using open source software. Especially if they have clear policies and processes that show they are actively tracking, reviewing and managing the open source software they use just like they would track their use of proprietary software.
Scoble just lost all his calendar events to a Mobile Me bug. He points out that:
Apple’s secrecy keeps them from properly testing out their apps with
tons of users, the way other companies do who aren’t so worried about
When people talk about open source software, they talk about the advantage of lots of testers. For example, Marten Mickos always talks about how he has two types of users with MySQL, those with lots of time and little money and those with lots of money and little time.
What I think doesn’t get enough attention is the fact that these "free users" aren’t your average user. They are usually very technical, very passionate, very active users. People that will help make sure you have the information to fix the problems they find. And if you label it a beta (as perhaps Apple should have done with Mobile Me), they know how to take appropriate precautions so that when terrible things happen, it doesn’t wipe out their data. Free and open source software developers can use and test your software in ways that the average user can’t or isn’t interested in doing.
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:
- 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.
- 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.)
- 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.
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?