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
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.
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.
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
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
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
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
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
are available if other people want to try the same kind of workshop.
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)
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)
You wouldn't flame a puppy, would you?
, deputy director of the new Microsoft-backed
, showed up at the Southern California
(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
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,
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
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,
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)
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
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
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
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
Comments (22 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Trustedbird: Additional email security for Thunderbird; New vulnerabilities in FFmpeg, Firefox, MoinMoin, SystemTap,...
- Kernel: Checkpoint/restart; 18.104.22.168; Huge pages part 2: Interfaces.
- Distributions: Proxmox VE 1.5: combining KVM and OpenVZ; Debian Installer 6.0 Alpha1; openSUSE Milestone 2; PC-BSD 8.0.
- Development: Google releases "Living Stories" code, project OsmocomBB launched, State of X.Org Foundation, Apache turns 15, new versions of Rivendell, MariaDB, MySQL, gujin, LTSP, Ecasound, Klactoveedsedstene, XMMS2, Scribus, Kicad, cairo, Wine, Sylpheed, Leo, Scilab, DreamPie.
- Announcements: FSF letter to Google, JMRI case settled, LAC Times, Hg tutorial, hackers in films, Karsten Wade interview, Arduino survey, 5 best video players, GPW cfp, RailsConf cfp, Collaboration Summit agenda, OOoCon Budapest, PostgreSQL Conf East.