Leading items

SCALE 8x: Moving the needle

There are lots of ongoing efforts to increase the number of women participating in free software, but reports on how those efforts have fared are few and far between. Sarah Mei spoke at the Women in Open Source (WIOS) conference, which preceded SCALE 8x, to report on what she and other members of the San Francisco Ruby community have been doing to bring more women into that community. Her talk, Moving the Needle: How the San Francisco Ruby Community got to 18%, looked at the goals that were set, the methods that were used, and the results.

Mei had been involved in various communities over the last 15 years, including Java, PHP, and Linux, and she had never really thought about why there weren't very many other women active in those communities. But, when coming back into the Ruby community after not being a part of it for a few months, she attended the Golden Gate Ruby Conference (GoGaRuCo) in 2009, which was infamous for a presentation that featured soft-core pornography in its slides. That conference, with around 200 attendees, five of which were women—including, in an amusing coincidence, three named "Sarah"—became something of a turning point for Mei.

She started out by posting about it to her blog, but soon realized that the presenter didn't really mean to be demeaning and was, instead, just a "socially awkward computer programmer". She didn't think she could change the person, so she started thinking about changing the community. In particular, if you could "change the audience at these events" such that it was 100 women and 100 men, she believed that inappropriate presentations would naturally fall by the wayside.

So she got together with one of the other Sarahs (Allen) to come up with ideas on how to get more women into the community. What they came up with was workshops to teach Ruby and Rails to women. But they also set a goal of 50% participation by women in two separate community events. The monthly Ruby "meetups", which had about 2% participation by women in January 2009, and the 2010 GoGaRuCo, which will be held in September, were the targets. As of January 2010, they are already up to 18% women at the meetups.

[PULL QUOTE: San Francisco is the "center of the Ruby universe", Mei said, with 1600 people on the meetup mailing list. In contrast, the Silicon Valley list has just 25 people on it. END QUOTE]

San Francisco is the "center of the Ruby universe", Mei said, with 1600 people on the meetup mailing list. In contrast, the Silicon Valley list has just 25 people on it. In addition, Ruby is "trendy", so people are interested, which made them think that free workshops for women covering Ruby would be popular, and "we were right". For other communities, other kinds of events might be better, and anyone targeting those communities needs to figure out what the right kind of event is.

So far, they've had three workshops attended by a total of 250 people. But events aren't all they do. There are three things that need to go together: setting goals, doing events, and cultivating people. Many efforts at community building focus on the events and "fail to set goals and cultivate the people that they get".

Goals should be very specific and should focus on something that you can fix. Mei had not gotten involved before because it seemed like such a huge problem to solve. By focusing on specific, achievable goals, like getting more women to come to each successive monthly meeting, they reduced the problem considerably. Now, that success with the monthly meetings can be used to assist the longer-term GoGaRuCo goal.

For the workshops, they decided to target very specific audiences. Targeting all women is not specific enough, nor is targeting all women developers. Their focus was two groups: women who had been out the workforce for a bit (often due to having a child) and women who work at companies that use Ruby, but aren't programmers. They used the Meetup.com infrastructure to organize the workshops, not because they liked it particularly, but because it tied in well with the existing monthly Ruby meetings.

The workshop logistics were not the hard part, she said. Finding a room, getting enough food, and getting sponsors was fairly straightforward. Sponsors were in fact the easiest part; they told people they wanted to train more women in Ruby and sponsors "threw money at us". One thing she suggested as a way to help people attend was to offer child care. They got a few husbands of attendees to volunteer and "locked [them] and the kids in a room with a Wii". Part of their target was moms, but even if that's not the case, offering child care can help as it may well be that both parents want to attend.

Attendance is not limited to women, as each women can bring a male guest. In addition, men are welcome as volunteers to help teach the workshop material as a TA. It's important to remember that the idea is to integrate women into the wider community, so adding men from the community to the workshop is important, she said. She also suggests having an after-party for all the participants and volunteers. Giving free drink tickets to the volunteers is a good way to get them to stick around for the party, which also helps with community integration.

Cultivating people is the other part of the puzzle. You need to "cultivate people at both ends of the pipeline", first by getting them in the door, and then, once they leave the event, by helping them continue in the community. Sending personal email—not mass email—to participants or potential participants is a good way to connect. They have also been successful in getting participants to volunteer to help with the next workshop, which is another way to keep the connection going.

Mei noted that it is much like sales. You need to get the word out to everyone you meet that might be interested. Printing up business cards with information about the workshops, posting information to a blog, and going to related meetings and conferences to talk about it are all things that can be done to attract more people. It is a "winnowing process", as some small percentage of those you tell will come and a small percentage of those will actually become Ruby developers. Getting five new developers out of the 200 women that have attended the workshops so far would make her happy.

Many women don't like to be visible in the community, but it is essential. When an organizing committee for a conference or event is not all-male, it says something about the organization. Women need to be willing to put their names on events, contribute on mailing lists, and ask questions after talks. She has noticed that it is mostly men who ask questions after a talk—"change that".

One of the interesting outcomes of the workshop effort has been higher attendance by women at the monthly meetings, some of whom hadn't come to one of the workshops. A critical mass effect has been achieved, so that "once the stigma was removed", more women started showing up.

Some unexpected things have happened, which may not be directly attributable to more women being involved, but they are correlated in time. The mailing list has been more active and lively, the talks are more varied and interesting, and more women are volunteering to give talks. She thinks that the influx of women, especially some asking more basic questions, has made the men feel more comfortable on the mailing list because they now "have permission not to know everything". They are more comfortable "not knowing all the answers", she said.

So, why is increasing women's participation so hard? Why haven't things like what has happened in San Francisco happened everywhere? Mei said that it really requires a woman or two to be willing to be visible. Their presentation materials are available if other people want to try the same kind of workshop. The problem is social, not technical, and, while we are "really good at solving technical problems", anything that is "a little more touchy-feely doesn't go so well".

What Mei and others have done in San Francisco looks promising as a model for other communities in other regions. As she pointed out, looking at the community to be served is important, as that will help focus the efforts in a productive direction. She is now evangelizing two things: the Ruby workshops in San Francisco along with using workshops as a tool to bring more women into the community. One can only hope she succeeds with both.

Comments (22 posted)

SCALE 8x: Free software legal issues

The casual view of open source software is that the code always comes first: releases are made when the code is ready, new contributors prove their chops by the quality of their code, and so forth. But in reality the FLOSS ecosystem relies on a complex legal framework in order to run smoothly and to stand up to proprietary software competition: the various software licenses, contribution agreements, copyright and other "intellectual property" law. Every once in a while, a good status check on the legal dimension is healthy for the typical developer, and SCALE 8x offered just that in a series of talks.

Red Hat's licensing and patent attorney Richard Fontana spoke about improving the intra-community open source legal system, Bradley Kuhn of the Software Freedom Conservancy and Software Freedom Law Center (SFLC) spoke about the nuts-and-bolts of bringing GPL violators into compliance, and SFLC counsel Karen Sandler presented a primer on the often misunderstood realm of trademark law.

Brave New World

Fontana's talk "Improving the Open Source Legal System" began by exploring how the real-world practices of the open source software community diverge from the legal realities on which the community depends. He then questioned what the differences reveal about the structure of the community, and suggested steps that major players like Linux distributions and large software projects could take to shore up some of the common misunderstandings and loopholes.

The conventional view of the software licenses that define FLOSS is that they are exotic variants of the licenses that govern the proprietary software market, Fontana said. They impose restrictions, albeit strange ones, and although there are peculiarities, similar peculiarities are found in contracts in the proprietary world, too. Ultimately, as in the proprietary world, participants comply with the licenses to minimize their own risk (in particular, the risk of litigation).

But in actuality, he continued, the FLOSS community acts according to a very different set of rules that are unique to the community. For example, the territoriality of licenses is almost universally ignored: developers act as if there is one, worldwide interpretation of the GPL, which is simply not true. The governing law of different countries can impose different restrictions, such as what constitutes software "distribution" (an example that the Free Software Foundation worked hard to correct for GPLv3 by using different language, such as "convey"). Proprietary companies take full advantage of the differences in local law, but virtually no one in most open source projects knows or cares what the governing law is in their case.

Similarly, there appears to be a set of widely-accepted functional rules for interpreting licenses that has arisen in practice outside of copyright law itself. For example, Fontana said, it is accepted universally that one can add BSD-licensed code to a GPL-licensed project, but in many jurisdictions the law states that a license (in this example, the BSD license) must explicitly address sublicensing or such sublicensing is not allowed.

Rather than strictly conforming to the legal system, Fontana continued, FLOSS functions on its own set of customs. They seem to be rational, but there is no formal description of them (which makes educating newcomers a problem), there are no institutions to handle dispute resolution, and some of the rules may not reflect real consensus. In the long term, this poses a problem for the legitimacy and rationality of FLOSS, he concluded. If we believe in free software ideals, we should strive to make FLOSS law meaningful and rational.

Fontana proposed several steps that vendors, projects, and distributions could take to better rationalize the system. These players should discuss and hopefully come to broad agreement on the boundaries between free and non-free behavior — acts such as nominally free projects shipping non-free code, putting portions of their code under non-free licenses, or applying anti-free interpretations to the licenses. They should also address murky "outbound licensing" issues such as how GPL and non-GPL code can coexist when shipped by the same project, and "inbound licensing" issues such as accepting code contributions without explicit copyrights and licenses attached.

The actual steps that Fontana recommends projects, distributions, and license stewards take come down to documentation and policing. Projects should publicly document their interpretations of licenses and definitions (something that some, like Debian and Fedora, already do). Distributions should document policies for code contributions and carefully police the licenses of the code they include. It is legally acceptable for the FLOSS community to have its own set of governing customs and traditions, but by and large, those customs are not yet documented and assembled — and they should be, for the long-term health of open source.

Lawyers, Code, and Money

Kuhn's talk "Demystifying GPL Enforcement" illuminated one of those traditions: what actually happens when a company is accused of violating the GPL by not the providing source code to a GPL-licensed upstream project (such as the kernel or the BusyBox utility) incorporated in its product. Kuhn works in GPL enforcement both for the SFLC, and as president of the Software Freedom Conservancy, the nonprofit group legally authorized by BusyBox (among other projects) to act on its behalf in enforcement.

Kuhn outlined best practices for doing compliance-friendly development, explained the different compliance options and the pros and cons of each, an outlined what SFLC does when it finds a GPL violation.

For the clueful, he said, avoiding violations in simple — many companies just don't take the steps. Violating companies, for example, never use version control, much less pull in GPL code from upstream as a "vendor branch." They also tend not to tag their releases, document or version their build process, or other common practices in free software projects. The result is that when someone makes a request for source code, it is impossible for the company to comply.

On top of that, he said, the companies he encounters in enforcement actions always make compliance more difficult for themselves by choosing the most arduous source code distribution options. The GPL allows several choices: include the source alongside the binary, make an offer to send the source code to anyone who requests it, and (in version 3), make it available through a peer-to-peer system.

By far the simplest option is including the source alongside the binary, said Kuhn, because the company's obligation ends immediately. In contrast, the offer to send source code upon request must be honored for three years after the last ship date of the project, applies to anyone (not just customers) and is considerably more logistically arduous. But most violators choose the "offer" option, he said, because they want to gamble that no one will actually request the code. They should assume otherwise, he said, since even if no one else ever requests the source code, Kuhn himself will.

That request is how an enforcement action begins; if the company does not comply, the SFLC sends a formal letter directed to the legal counsel or CEO, and attempts to open up active discussions on how to bring the vendor into compliance. Most of the time, the channel of communication is opened. The SFLC makes a series of standard requests, and works with the company to come into compliance on all FLOSS-copyrighted software incorporated in their products. The requests include putting the proper processes into place (including not just the development processes mentioned above, but keeping appropriate records and appointing someone in the company to be in charge of GPL compliance), notifying past recipients of the violating product that source code is now available, and for a financial settlement.

The settlement money is at times controversial, but Kuhn explained that it has several purposes. First, if there was no penalty to GPL violation other than coming into compliance, no one would proactively comply. Second, given that there must be a deterrent, the SFLC feels that GPL violators should bear the cost of defending GPL-licensed software projects — not companies who uphold the GPL, and not individual free software developers. SFLC is a nonprofit, he added, and does not get rich from settlement money. In fact, its status as a nonprofit entity enforces a degree of transparency on the entire enforcement process, with records on file with the IRS.

Only in rare cases does a GPL enforcement action result in a lawsuit, Kuhn said. It has happened in the past, but only after a complete breakdown in communication, and after considerable effort to bring the company into compliance. Kuhn prefers to to think of every GPL violator as a potential new contributor to the FLOSS community, and tells himself that every time he picks up the phone to make a request for source code.

GPL enforcement clarifies that there is one community, with one set of rules — not one set for those who choose to participate, and one for those who choose to remain ignorant. Enforcement itself shows that the community's rules are meaningful, he said, and doing it through a nonprofit group like the SFLC takes the burden off of the individual developers, who don't have the time to pursue violations themselves.

On your mark, get set...

Sandler's talk "What You Need to Know About Trademarks" addressed the legal concept of trademark, the understanding of which (like copyright) is vital to the health of free software projects. A trademark lets a small project protect and defend its identity even against well-funded competitors, but it is a very different animal than a copyright, which forms the foundation of FLOSS software licenses.

Copyright is granted automatically when a work (including software) is created. In contrast, a trademark is created automatically when it is used. The mark, whether a logo or a name, does not need to be registered; instead it is earned and strengthened by its usage. The more one uses a trademark, the stronger it is when challenged in court. Trademarks are also not subject to expiration terms like copyrights; as long as they are continually used, they do not ever expire and enter the public domain.

The legal test for trademark violation is in "the eye of the beholder" — almost literally. The test, Sandler said, is whether or not there is an identity associated with the mark in the public eye. In other words, when a person sees the mark, do they associate it with a particular product. Trademarks are limited by political geography, with different laws in different countries, and are only applicable to the industry or field-of-use in which the trademark is used.

Trademark law does have parallels to more familiar copyright law concepts, though. Where copyright has the doctrine of "fair use" protecting citation, commentary, and parody, trademark has "nominative use" which protects the use of marks to refer factually to the actual trademarked product. In other words, stores can use trademarked names and logos to advertise that the products mentioned are for sale, without seeking permission.

Sandler also addressed two trademark uses of interest to FLOSS software projects: developing a trademark for a project, and responding to "nastygrams" from hostile trademark holders.

Choosing a good trademark involves picking a distinctive name or logo. Commonly-used terms associated with the product cannot be trademarked, and choosing a good mark can be difficult. Sandler recommends doing a trademark search; unlike patents there is no doctrine of "willful infringement" in trademark — trademark infringers are just ordered to stop using the mark. But projects should be careful about their trademarks; registering a trademark is not required, but if it is done, she recommends having the group apply for it collectively, not leaving it up to an individual. An individual holding the mark could leave or fork the project later, thus making it very difficult for the group to regain control. Projects should also create a trademark policy, stating acceptable uses, naming conventions, and merchandising policy — not doing so could create confusion later, ultimately diluting the mark.

Finally, Sandler addressed what to do if a trademark holder accuses a software project of infringing on its mark. The principle question to ask is if the accused usage is genuinely likely to create confusion in consumers. Are the marks similar? Are they in the same field-of-use? Do they give the overall impression of being related products? And, most importantly, does the accuser know of actual cases of consumer confusion? If the answer is no, then there is likely no real infringement. A project should begin by asking those questions, and only needs to worry or seek legal advice (including from SFLC) if the accuser continues.

I learned the law, and we all won

All three talks touched on one common problem: that free software developers are not lawyers, and often prefer not to dwell on potentially thorny legal issues. But the law should not be intimidating to FLOSS software projects; it protects them from abuse by well-heeled enemies, and although it is a different domain, it is certainly well within the grasp of anyone capable of writing device drivers, 3-D animation studios, or any of the other top-notch projects produced by the open source community.

Comments (1 posted)

SCALE 8x: Proprietary software companies and open source

You wouldn't flame a puppy, would you?

Mark Stone, deputy director of the new Microsoft-backed CodePlex Foundation, showed up at the Southern California Linux Expo (SCALE) with a laptop running Puppy Linux, complete with adorable desktop puppy logo. Stone's presentation, shown in the "Puppy HTML Viewer" application, set a new record for graphic simplicity, even by the standards of this year's SCALE, where any slide format other than the OpenOffice.org Impress default was rare.

While the CodePlex Foundation itself is new in 2009, Stone was at the event to make a familiar pitch: companies that do proprietary and in-house software development still need to be persuaded to act in their own best interests, and need help to decide to participate in open source development when they can derive benefit from it. Stone has been making the same point as an editor for O'Reilly and Associates, where he edited the essay collection Open Sources along with other titles, then later as director of the developer relations program for SourceForge. And, he argues, the point still needs to be made.

The CodePlex Foundation, which Stone called a "broker that can mediate", recently saw its first release of a non-Microsoft project, the MVC Contrib model-view-controller framework for the Microsoft ASP.NET platform. More releases, not all .NET related, are on the way, Stone said.

Any big company is likely to be a user of some open source software, he said, "but when you look at what of their own software they release as open source, some are doing better than others", Stone said.

The situation is better than it was in 1995, when almost all free software development happened off the corporate clock. "The trend is for corporate development and open source to overlap more and more." But, he said, the shift to paid development has been more a matter of open source developers getting paid to do it, and less about proprietary or in-house software developers being able to release their work. Open source developers are getting paid to work for companies, but what about taking corporate development organizations and getting them plugged into open source?

Understanding decision makers' motivations is vital. While most software developers view innovation as a good, often the people who make decisions at companies value predictability and "protecting the brand" over improving the product. "Innovation is risky and scary, and something to be avoided at all costs", he said. What goes into the product is a brand management decision.

Some businesses are friendly to customer innovation, and actively look for how people are misusing the product. Skateboarding started with proto-skaters modifying surfboards and scooters, and today, "extreme" sports vendors bring customer's modifications in-house and base products on them. Others are more conservative.

Knowledge above code?

Stone argues that full-bore participation has value that throwing code over the wall doesn't. "The mere act of releasing some code isn't that much. What we care about is not code sharing but knowledge sharing. The source code by itself doesn't actually transfer that much knowledge", he said. "If you want to understand the software you have to understand its caretakers."

Another difference is that companies intend to put more knowledge into formalized systems. In open source, "we're very comfortable with a tribal approach to knowledge," Stone said. Companies, on the other hand, want knowledge better nailed-down and formalized. "They want you as an individual to be replaceable." Differences may be more aspirational than real. Anyone who has tried to build a proprietary or recently-freed codebase for the first time will understand how much "tribal" knowledge is still there. "There are good practices on both sides", Stone said. The "replaceable" individual is impossible in open development, though. "Reputation travels with you as an open source developer", he said.

The process of how to do open source has gotten much easier, with the rise of easy-to-use project hosting sites such as the original SourceForge, Google Code, and GitHub, and what Stone called, "consolidation around a half-dozen or so key approaches to licensing." The hard part, though, is still the decision of whether or not to do open source in the first place. "For business decision-makers, 'why would we release something as open source?' is a hard question."

A common example of a good case for participating is a company that finds itself carrying a substantial "patch load" of local modifications to open source software. For example, Stone worked on a project that modified MediaWiki to add role-based access control support, not part of the upstream project at the time. Do you just carry the patch load, and reapply your modifications when getting a new upstream version, or attempt to participate in the process by offering changes to upstream, or gathering other users and forking the project? Even thinking about the question is outside some users' vision. "That open source decision is a possibility you need to get business decision-makers to think about."

If your worst problem is differences in development practices, he said, "Congratulations, you're 90% of the way there. Good software development looks very much the same," whether it's open or proprietary. "Don't assume there are differences that aren't really there", he said. In addition, corporate decision makers need to learn to disbelieve myths, such as the myth that open source can't do software testing.

What's missing?

Companies expect a legal entity on the other end of a contractual relationship. For example, Microsoft receives automatically generated crash dumps from software running on its Windows platform. But user data is confidential, and Microsoft won't share customer data without an NDA. Someone needs to enter into one in order to see the crash dumps. There are many existing umbrella organizations, but, Stone said, "We exist because none of them is meeting all the needs." Microsoft itself has done some open source releases but the foundation "will make it easier to participate."

The foundation is not tied to Microsoft hosting infrastructure. The new MVC Contrib project has a project profile on codeplex.com but keeps its source code hosted at GitHUb. (Codeplex.com documentation only lists revision control support for Mercurial, Subversion, and Microsoft Team Foundation Server).

For companies to use the CodePlex Foundation is like "not reinventing the wheel" in software, Stone said. "There are legal processes that you want to re-use and leverage as well." With a substantial staff and million-dollar budget, the new foundation is prepared to be flexible helping companies with the legal paperwork. The Apache Software Foundation has one contributor agreement, and one license, but CodePlex can customize these things. "What do you need in terms of contributor agreement and license?" Stone asked. More news will be coming at next month's Open Source Business Conference in San Francisco, Stone said.

Previous commenters have reacted to the prospect of a wholesale dislocation of the software business with something less than panic. Richard Stallman famously pronounced, "Writing non-free software is not an ethically legitimate activity, so if people who do this run into trouble, that's good! All businesses based on non-free software ought to fail, and the sooner the better." Paul Graham later wrote, "When I say business can learn from open source, I don't mean any specific business can. I mean business can learn about new conditions the same way a gene pool does. I'm not claiming companies can get smarter, just that dumb ones will die." Stone and the CodePlex Foundation are offering an alternative that doesn't involve an office chair auction and a massive dump of perfectly good business cards into the recycling bin.

Comments (1 posted)

LWN editor Forrest Cook moves on

I would like to announce my departure from the day-to-day operations at LWN.net. There are a number of factors behind this move. My leaving LWN will reduce the site's expenses in these difficult economic times, this move will allow the company to operate with greater economic flexibility.

After nearly ten years of dealing with weekly deadlines, processing countless software release announcements and performing many other behind-the-scenes tasks, your editor is ready for a change of direction. I plan on dedicating more attention to my Linux-powered CirKits.com mail-order solar power electronics kit company, an early off-shoot of the LWN parent company, Eklektix.

Working for LWN has been a great journey since writing my first feature article. Linux has grown from a small project into a real force in the operating system landscape. Linus's quest for world domination turned out to be more than just joking around. One can derive a lot of satisfaction from knowing that one's contributions, however small, may have helped to push this mighty project forward.

Never one to have any idle time, your author is looking forward to dedicating more effort to his ongoing solar and wind powered off-grid mountain house project with its accompanying alternative energy experiments. He plans to spend more time with electronic circuit tinkering, combining microprocessors with vacuum tubes, and playing around with electric guitars.

Comments (22 posted)