Open Source eBook Copy

8/12/2019 Open Source eBook Copy

1/54

AN OPEN WORLD:

STORIES FROM THE OPEN

SOURCE COMMUNITY

A collection of essays and interviews from opensource.com

Open Visions Issue Two


2/54

The day TuxPaint became contagiousPhil Shapiro

Introducing students to the world of open source: Day 1Asheesh Laroia

The four capital mistakes of open source

Nicolas Pujol

Rethinking office designRebecca Fernandez

Total victory for open source software in a patent lawsuitRob Tiller

Interview: PJ on the beginning, ending, and future of GroklawRuth Suehle

Student participation in open source projects (A professors perspective)Heidi Ellis

Three unspoken blockers that prevent professors from teaching open sourcecommunity participationMel Chua

Join the M revolutionGet your toolsLuis Ibanez

Open source cancer researchLori Mehen

History of open source in governmentGunnar Hellekson

Document Freedom Day: Passion and politicsKarsten Gerloff

3

5

9

11

16

18

23

27

31

36

40

46

LIFE

BUSINESS

LAW

EDUCATION

HEALTH

GOVERNMENT

IN THIS BOOKLET


3/54

1Introduction

INTRODUCTIONOpensource.comlaunched January 25, 2010as a platform for discussing the ways opensource is changing the world. Since then,weve helped our community share hundredsof stories about the power of open sourceprinciples to spark radical change. Each ofthese stories is an inspiring testament to the

wonderfuland often surprisinginnova-tions a commitment to open source valuescan generate.

Every one has been a pleasure to tell. Weveexplored some unanticipated topics overthe years, but weve never wavered fromour original mission: to shine a light onthe places where the open source way is

magnifying ideas and multiplying effort. Andwe remain especially interested in topicsbeyond technologydevelopments in areaslike government, education, business, health,law, and everyday life, where open sourcecontinues to grow.

Weve noticed that once you become attunedto open source valuescollaboration, shar-

ing, meritocracy, transparency, participation,community, and rapid iterationyou start tosee them everywhere. Eventually you mightwonderlike we dojust how different ourworld could be if everyone embraced them.

This collection offers some of our mostcompelling storiesportraits of a worldfashioned with a passion for open source.Here youll find tales only our commu-nity members could tell. Stories from thetrenches. From the library. From the cubicle.From the capitol. From the classroom andthe boardroom and the courtroom.

Anywhere open source is making wavesand turning heads.

While bringing these stories to the worldis easy, selecting just twelve of them forinclusion in this inaugural best of collectionwas not. Our opensource.commoderatorslobbied hard for their many favorites. The

essays youre about to read are among thevery best we have to offer from our first yearand half of publicationdazzling gems thatrefract and intensify that light we shine onopen source.

Read them, ponder them, and dont forgetto share them.

Then join the conversation at opensource.com. We have many more stories totell together.

Perhaps one of them is yours.


4/54

AN OPEN WORLD:

STORIES FROM THE

OPEN SOURCE COMMUNITY

LIFE


5/54

3The day TuxPaint became contagious

I work at a public library with 28 Linux sta-tions made publicly available in four separaterooms. The room in which I spend most ofmy time has 10 computers, and elementaryand middle school students stop by dailyafter school to use them. About 90 percent

of the children use the computers for games,and about 10 percent use them for doinghomework. Very few use the computer forcreative graphics applications. Im bent onchanging that.

Our computers run three very interesting,fun, and useful graphics programs. Foryoung children, we have TuxPaint1. We also

have the Inkscape2vector drawing programand the GNU Image Manipulation Program3

known as the GIMP. A few years ago ourlibrary offered a GIMP class for elementaryschool students. It was a joy seeing thestudents continue using GIMP after theclass came to an end. Unfortunately, the

GIMP contagion did not spread beyond thestudents in the class.

Last week, I was really happy to see amother sitting at a computer with her3-year-old son, with TuxPaint up on thescreen. The child was squealing with delightas he used the various drawing tools inTuxPaint. Listening to him speak, I noticed hewas highly verbal, too. How old is your son?I inquired politely.

The mom smiled back and said, Hes three.

I explained that TuxPaint was a free programand that the family could use it at home.

Mom told me the family has a laptop, soI offered to install TuxPaint the next timethey visited the library. (TuxPaint runs on allcomputer platformsLinux, Macintosh,and Windows.)

I did not expect what happened next.Somehow, the word about TuxPaint spread

THE DAY TUXPAINT

BECAME CONTAGIOUSPhil Shapiro(originally published May 2012)


6/54

An open world: Stories from the open source community4

throughout our community. Older elementaryschool students started exploring it in ourcomputer center. A few days later, a middleschool boy asked how he could use TuxPaint

on his computer. This is a boy who hasspent hundreds of hours playing first-personshooting games.

This student went on to make a lovely draw-ing in TuxPaint. I commented, Youve gotartistic talent.

He replied, My teacher once asked me todraw a bunny rabbit for Easter and I drew a

really excellent rabbit.

I offered to print his drawing on our colorlaser printer. Thats when I noticed that Tux-Paint was on most of the computers in ourcomputer center. A TuxPaint epidemic wasfull-blown. Students of all ages were explor-ing different aspects of the program.

I showed the sixth-grade studentsdrawing to a fourth-grade girl who wasenjoying TuxPaint.

Im going to try and make the same drawing,the fourth-grade girl said.

Can she borrow your drawing for a littlewhile? I asked the sixth grade boy.

He said, Fine!Within a span of 10 minutes, the computercenter had transformed itself from a games-playing room to a room full of creative explo-ration. I cant explain how it happened, but Igive a lot of credit to the programmers whocreated TuxPaint. For those of you who workwith youth in outside-of-school settings,

there is hope that students will voluntarilymove themselves off a games-playing pathand onto a creative exploration path.

TuxPaint, Inkscape, and GIMP are all freetools for creative exploration. It is possible tosee these programs making their way intoyour community. I can tell you first-hand,

its a truly beautiful sight.If you have ideas or tips for how to spur acreative epidemic with these and other FOSSprograms, comment below orevenbetterconsider writing an article for open-source.com. This is the tip of the iceberg.Reveal to us some of the rest of the iceberg,wont you?

1. www.tuxpaint.org/

2. www.inkscape.org/

3. www.gimp.org/


7/54

5Introducing students to the world of open source: Day 1

From Blake Ross to Linus Torvalds, studentsare credited with major achievements in the

open source community. But thats not thepicture Yuvi Masory painted as he sat acrossthe table from me at an OpenHatch meetupin Philadelphia.

My lab is hiring, he explained. We needstudents with programming experience andwho can find answers to questions. But thestudents at Penn have never even heard

of IRC. Theyve never contributed toopen source.

Yuvi is a graduate student and staffprogrammer. He implored me to come tocampus and give a one-hour talk to under-graduates about OpenHatch1, my project to

help new contributors find their way inthe community.

Give me a weekend instead, I said.

A weekend of immersion

We scheduled a planning session betweenYuvi, myself, and Felice Ford, a Linux-lovingclassics major at Harvard who was visiting.

We settled on two days of rich interaction.Even though programming students can

write code, most never see a bug tracker,and very few learn about version control.This creates a cultural rift where plenty ofpeople bounce off2open source projectsbecause of build problems or lack of com-munity leadership. We wanted to be there tohelp students past problems like that.

INTRODUCING STUDENTS

TO THE WORLD OF OPENSOURCE: DAY 1Asheesh Laroia (originally published November 2010)


8/54


We put up a website explaining the event3.For Saturday, we planned four one-hoursessions. Each session focused on a differenttopic and offered students some hands-

on exercises. The second day was a moretypical hackathon, a project day where wehelped students find their way in projects oftheir choosing.

To create a sense of commitment from stu-dents, and to ensure a tight student-teacherratio, we limited Saturday to 20 students. Tohelp us prioritize people who were particu-

larly excited, and particularly new, weasked for:

One sentence about how they discoveredthe event website

One sentence about their current involve-ment in open source (e.g., never heardof it, run Ubuntu, wrote most of theLinux kernel)

One sentence about something they wereexcited about learning

Since our goal was to make more studentsaware of open source culture, we wantedto work directly with students to kickstart alocal community. This strategy is unique, asfar as we know. You may have read about

the Professors Open Source Summer Experi-ence4that teaches professors so that theycan run a semester-long class for students.

Will they come?

To get the word out, we asked the Universityof Pennsylvanias computer science programto email all 250 of its students. We also

reached out to students at Swarthmore andother nearby colleges. Yuvi put up enigmaticindex cards, and a friend of his put up flyers.

Within minutes of sending the announce-ment, the emails started rolling in. By theend, we heard from fifty-one applicants.Immediately overwhelmed, we switched

from worrying about advertising to readingthe applications.

What feels normal to us is apparently ex-tremely exciting to these students. Reading

the emails was like reading fan mail. Somewrote such gems as this:

My involvement with open source isprimarily composed of unabashed admi-ration and adulation.

Im most excited to learn how to initiallyget involved with a project, Ive poked

around before, but the initial learningcurve has been too intimidating for me totake the plunge.

I have just read a lot about open sourcesoftware. Im really interested in howsuch collaborations create innovativeand effective products (Firefox!), as wellas the business perspective of how

these collaborations are organisedand run efficiently.

Id be excited about learning pretty muchanything that has to do with open sourcesoftware, the communities that create it,and its social impact.

I hope I make it! This sounds terriblyinteresting!

I just sat at my computer, reading and re-reading, saying aloud: This is so exciting!These people are so excited!

The students came from a wide variety ofethnic and cultural backgrounds. More thana third of the applicants were women, a(slightly) more even ratio than the Penn CIS

program itself. Yuvi and I selected the thirtymost excited students and told them to meetus on Saturday.

Now we needed teachers. Felice had cre-ated #penn on Freenode as a chat roomfor our burgeoning community. To our luck,


9/54

7Introducing students to the world of open source: Day 1

a GNOME hacker named Zach Goldberg5appeared in the channel, and we convincedhim to take a bus from New York to his almamater. My friends Jonathan Simpson6and

John Stumpo7

rounded out the teaching team.We spent Friday afternoon and evening nail-ing down logistics. Around 1 a.m., Yuvi andI decided to switch which topics we wouldteach. Felice organized the students intogroups based on their level of experience.Finally, we could all go to sleep.

One busy Saturday

The teachers all arrived by 10 a.m., and weset up wifi for the students to use. Teacherstaught the same topic four times in a row, sowe had the chance to improve our curricu-lum. Students switched between teachersand took a whirlwind tour of four areaswithin the open source community:

Communication technologies, like IRC andmailing lists

How to get, build, and modify opensource code

Project organization, including versioncontrol, bug trackers, and individual roleswithin a project

Linux and command line skillsWe broke once for lunch, and another timeto discuss free software ethics in generaland licensing specifically. Finally, after stu-dents had visited all four modules, we had anopen discussion to wrap up the day. About

twenty of our thirty students stuck throughuntil the end.

Much feedback was positive. One studentsaid about contributing to open source, You

made it feel a lot more doable. He contin-ued, You dont have to be a pro programmerto help or contribute something. Anotherenjoyed the variety of teachers and their

different personalities, the different takeon things.

One student was particularly taken by thediscussion of principles and ethics behind

the free software movement. It puts ev-erything in a different perspective, she saiddefinitively. However, she found our use ofthe term hacker a jarring distraction.

Toward the end of wrap-up, a student askedus when we would be running another event.At that moment, Yuvi and I looked at eachother in disbelief.

Overall, students enjoyed the down-to-earthnature of the event. One student enjoyedour conversational tone and explained, Itwas good to learn that open source peoplearent cyborgs. Another called upon us toContinue to keep it free [of charge]!

Whats next?

Read about day 2 and holding yourown event8.

Check out our photo gallery9, snappedSaturday and Sunday.

1. http://opensource.com/life/10/8/ready-be-open-source-contributor-dont-know-where-start

2. http://jonoscript.wordpress.com/2010/09/28/improving-the-discovery-path-for-new-contributors/

3. www.penn.openhatch.org/old-index/

4. www.opensource.com/education/10/9/open-source-education-educators

5. www.zachgoldberg.com/

6. www.sogeekithurts.com/

7. www.jstump.com/

8. http://opensource.com/life/10/11/introducing-students-world-open-source-day-2

9. http://openhatch.org/blog/2010/photos-from-penn/


10/54

AN OPEN WORLD:

STORIES FROM THE


BUSINESS


11/54

9The four capital mistakes of open source

THE FOUR

CAPITAL MISTAKES

OF OPEN SOURCENicolas Pujol (originally published February 2011)

How do you develop a successful opensource business that lasts? Of the more than250,000 open source projects on Source-

Forge, few will be successful at that goal. Butone way they might think about how to doit is by doing it in reverse: What should anopen source project or business not do?

The negative advice has existed since ancienttimes, from one religion to another. The TenCommandments are for the most part writ-ten as what not to do. We can go for a shortwalk or drive around our neighborhood: roadsigns give us, in very short messages wecan read while driving, negative advice. AskWarren Buffett about finance. Hell tell youRule #1 is Dont lose money, and Rule #2 isDont lose money.

Open source can also be better understoodthrough negative advice. The latter can beback-tested and endure the test of time.

By following a positive framework (butwithout falling into platonicity), one canslightly increase the chances of success. Butby ignoring a negative one, you will mostcertainly fail.

First negative rule: Reflexivity

Dont try to sell the same product you are

giving away for the same use case.As a business, open source is built onsequential sets of events. Free softwareand openness create an economy basedon non-monetary transactions. Instead ofmoney, people trade their time and, gener-ally, their mind share in exchange for value.


12/54


It is the Mind Share Market. As this happens,another economy takes shape that followsthe more common path of transactions usingmoney: the commercial market. In order for

the model to work, what is free and paidmust necessarily be complementary, there-fore different. Differentiation is at the core ofall open source businesses, and its opposite,reflexivity, is where the business tries tosell the same good that it is giving away forfree. Reflexivity is destructive, as it starvesthe provider and prevents the business fromdeveloping financiallyi.

Second negative rule: Coercion

Artificial fences are self-defeating.

One of the key reasons customers chooseopen source is freedom. Coercion is theopposite and relies on forcing third partiesto behave in a certain way. At its roots, opensource exists because customers do notwant to be forced. The practice is henceself-defeating, even if it can work on thecommercial market in the short run. Coercionis viral: it can over time tarnish the broadperception of open source as a deceivingscheme and may invite others to do so iftemporarily successful. Barriers to entry andexit are necessary, but in a Peter Drucker

style that seeks customer respect.

Let others deal with legally acceptabledeception.

Third negative rule: Isolationism

What works in some contexts doesnt workin open source.

Ecosystems thrive on extensibility and dieof bureaucracy. The ability to access code,to re-distribute it in certain scenarios, andto enable interactions with other compo-

nents gives open source an advantage notreadily available in many other businessmodels. Hundreds of thousands of engi-neers (potentially one day, billions of people)

working together and contributing value canoutcompete a large corporation with thesame number of engineers on its payroll. Butfor this to happen, collaboration must beextremely simple. Observe technologies likeLinux, Firefox, WordPress, MySQL, Androidor Wikipedia: they make it easy for others toextend their platforms from the peripheryto the core; almost invasively. Isolationismblocks collaboration, partnerships, appli-cation programming interfaces (APIs), anddefeats the purpose of being open.

Fourth negative rule: The salary addiction

Dont do anything only for moneyespecially open source.

The last capital mistake requires some con-text. There are situations where a job and asalary must take absolute precedence overpurpose. A job may be just a job to supporta family.

In other situations people end up in rolesthey didnt have to accept, but did so onlyfor financial reasons. Phoniness is the last

capital mistake of open source: it is notonly immoral, but often counterproductive.People with a sense of purpose would dowhat they do for free, regardless of incentive.The latter exists, but cannot be the primarydriver of action. Matt Mullenweg likes to saythat code is poetryii. Poetry is not createdon a mechanical assembly line. Passion doesnot always translate into business momen-tum. Revenues do matter. But if you seeopen source as only business you will neverunderstand it.

i. Even Wikipedia, a nonprofit with nothing for sale,does not give everything away. It retains itsbrand, infrastructure and ad space (used todayfor donations).

ii. This applies to code and to any other value gener-ation and collaborative work; you are reading thisarticle on opensource.com.


13/54

11Rethinking office design

First, a confession. Despite the hip corporatepersona of Red Hat, when I first joined thecompany everyone had typical cubicle farmworkspaces. Sure, there were hints that the

company aspired to Google-like coolness: afoosball table, a game room, lots of free junkfood. But in our daily office-worker lives, wewere holed up in a standard maze of sharedcubicles. Our idea of open office designwas to persuade our cubemates to leave thesliding doors open.

For six months, I labored happily in my gray

box, content to talk only with my supervisorand my cubemate. So when the departmentdirector announced that after the Christmasholiday week, wed be moving to a new openspace downstairs, I groaned inwardly. The cubi-cle walls were being removed; the department

VP and managers would work in the same areaas everyone else; and the new space wouldinclude lots of nooks and rooms for impromptucollaboration and scheduled design-thinking

sessions. As the lone quiet, left-brained webdeveloper among a host of creatives, I was cer-tain this sudden push for collaboration meantId never get any work done.

I was mistaken.

According to the 2001 office design study,Offices That Work: Balancing Communica-

tion, Flexibility and Cost (pdf)1

, the majorreason for an office today is to bring peopletogether: to socialize and share information;to inspire and inform each other; to provideguidance and feedback. Relatively little of thework of most office workers requires deep,individual concentration for hours at a time.

RETHINKING

OFFICE DESIGNRebecca Fernandez (originally published May 2010)


14/54


As a computer programmer, I was not exempt:

As the literature on computer engineers shows,

this is true even for the prototypical job function

requiring deep concentration. There do need to

be times and places for such work in the office,but whether such places need to be assigned to

one person for his or her exclusive use, or requires

complete physical separation from others doing

the same work, has been challenged by many

corporations over the past decade.

Within a month in the new workspace, Iknew more about every colleague in my

department than Id learned over the priorhalf-year. My own role deepened from beinga ticket-resolving web monkey to a full-fledged knowledge worker and vital part ofthe team.

My fears about moving out of my cubicle

1. Without cubicle walls to hide behind,interruptions would be endless.

In one sense, there are more interruptions.Communication is abundantand morefrequentwhen you can see your teammembers. But the rapid flow of informationthroughout the office actually reduces theemail, phone calls, and traditional scheduledmeetings needed, according to the studylinked earlier. Surprisingly, increased visual

contact actually contributes to fewer un-wanted interactions. When you can glance ata coworker and see that they look engagedin a problem or irritated by a phone call,youre more likely to ask your question laterthan if you had walked down the hall andalready poked your head into their office.

The study also notes:

Our data suggest that individual performance or

productivity may be reduced in a given unit of

time, while both individual performance and that

of their team benefit over the life of the project.

In other words, this minutes interruption can be

annoying, but over the life of the project such

interruptions tend to be seen as contributing to

overall success.

2. In an open office design, there would benowhere to go when I needed to hold

a private conversation or think intentlywithout interruption.

A well designed open layout includes placesfor these tasks. When Cisco redesignedtheir offices2to be more collaboration-friendly and reflect modern work habits, thecompany opted for a highly flexible design.Only administrative assistants were assigned

longterm office desks; no one else has own-ership over a particular workspace. Insteadthey choose the type of workspace theyneed for a few minutes, hours, or all day:

Cisco employees are increasingly mobileand

less and less working at a particular desk ...

Throughout the day, employees [select] an ap-

propriate environment to accomplish the task at

hand: meeting in a group, participating in a con-ference call, or working alone on a spreadsheet

or project plan.

The Cisco plan includes a quiet area deemedthe library for work requiring intense con-centration and quiet, as well as an etiquettepolicy, developed by employees along theway, which frames the use of different areas:

non-private meetings with one other personshould take place in smaller, open seatingareas, not a closed conference room,for example.

The decision to change the Cisco office de-sign was made after considerable thought:

Like most companies, Cisco designed its office

space under the traditional assumption that em-

ployees would work in their own cubicles during

regular work hours and would need assigned work

spaces with their own desks, PCs, and phones.

The result was that meeting rooms were often in

short supply, while offices and cubicles remained

vacant 65 percent of the time on average.


15/54


16/54


1. http://tinyurl.com/8tfn4es

2. www.cisco.com/web/about/ciscoitatwork/collab-oration/connected_workplace.html

3. www.officesnapshots.com/

4. www.hbswk.hbs.edu/archive/4991.html

5 www.bnet.com/2403-13056_23-190685.html

the ability to check voicemail and makephone calls from any workstation.

3. Limited number of collaboration areas

We didnt anticipate the culture shift thataccompanied moving into a new spacewould require more spaces for collaboration.Smaller areas for non-private meetings and asecond closed-door conference room wouldhave made our space a bit more usable.

4. Neighbor immigration

Our department, Brand Communications +

Design, was the first to receive permissionand funds for an open office design. Thatspace included a large, open meeting areawith several whiteboards and comfy chairs.As employees from other departments wereinvited to meet with us, they quickly noticedwhat vibrant and collaborative meetingssprung from the space. Lets meet over in

the Brand Comm space became a commonrefrain for anyone looking to hold an infor-mal and insightful meeting. Unfortunately,our space was not designed to host meet-ings for multiple departments, and creatingsimilar spaces in those departments wouldhave been a valued decision.

5. Shifting requirements

An open office design must be regarded asa work-in-progress. As new needs emerge,the space must be able to accommodate. AtCisco, this meant adding personal lockers forpurses or lunches, and larger filing cabinetsfor employees whose jobs required themto store forms or records. Within the BrandCommunications + Design space at Red Hat,

the function of several closed-door roomshas changed over the years, serving as

everything from a video recording studio to alibrary to a temporary office.

Real-world examples

So what does the open office look like? Andhow does a businesswithout the budgetof a Google or an IDEObuild an equallycollaborative environment?

The Cisco case study shows that open officeenvironments are actually more cost-effec-tive than more traditional types. A buildingwith large, closed-door office rooms could

convert those private rooms into door-less,team bullpen rooms, where several col-leagues work together. A department withcubicles could remove the walls and replacethem with interconnected desks and smallermeeting areas. The ideal open office projectwould include its future inhabitants in thedesign process.

There is a lot of inspiration to be found atwww.officesnapshots.com3, with picturesof office spaces from Microsoft to Apple,Twitter to Facebook, and plenty of smallerbusinesses as well.

Articles like Why Office Design Matters4from Harvard Business Review, and BNetsThree New Designs for Optimizing Collabo-

ration5provide additional ideas and casestudies.

But more valuable may be talking to peoplewho work in open environments about theirexperiences.


17/54

15Introduction

LAW

AN OPEN WORLD:

STORIES FROM THE



18/54


TOTAL VICTORY

FOR OPEN SOURCE

SOFTWARE IN A

PATENT LAWSUITRob Tiller(originally published May 2010)

The jury verdict last Friday in favor of Red Hatand Novell in a case based on bad softwarepatents owned by non-practicing entitiesis an important victory for the open sourcecommunity. Those in the business of acquir-ing bad software patents to coerce paymentsor bring lawsuits should be worried. Twosuch businesses were plaintiffs in our case,and they did their best to confuse the jury inone of their favorite locales, eastern Texas.But it didnt work. The jury unanimouslyfound that the patents were not infringed,and, even worse for the plaintiffs, that thepatents were invalid.

The case was about allegations by IP Innova-tion, L.L.C. (a subsidiary of Acacia Technolo-

gies), along with Technology Licensing Cor-poration that Red Hat and Novell infringedfour claims from U.S. Patents 5,072,412,5,394,521, and 5,533,183. The patents sharea common disclosure and are all titled Userinterface with multiple workspaces forsharing display system objects. The patentsrelate to a computer-implemented systemand method for providing a graphical userinterface with multiple workspaces.

Like most patent cases, this one involvedtechnical subject matter and terminology.However, the plaintiffs came forward withminimal evidence to support their argumentof infringement. They also faced abundantevidence showing that the patents were


19/54

17Total victory for open source software in a patent lawsuit

invalid based on prior art. In other words,there was nothing new in these inventionssufficient for a patent.

In these circumstances, you might suppose

that a rational patent plaintiff would dismissthe case, perhaps in return for a tokenpayment. Instead, the plaintiffs decidedto ask the jury for millions of dollars. Theirtheory appeared to be that the jury mightbe confused by the technical terms andunsympathetic to out-of-state businesseswith creative business models.

With that end apparently in view, theplaintiffs counsel launched an attack on thetheory and practice of open source software.It was clear during jury selection that our

jurors had no prior knowledge of, or experi-ence with, open source. Plaintiffs attemptedto exploit this inexperience by arguing thatopen source software involved behavior that

was, if not downright illegal, at least ethicallydubious. They promoted the fallacy thatopen source distributors unfairly take theproperty of others and thereby unfairly profit.They also suggested that Red Hats publiccriticisms of the U.S. patent system as itrelates to software and related calls for legalreform were un-American and indicated a

secret fondness for the writings of Karl Marx.I kid you not! As absurd as this argumentsounds, after many hours of sitting on a hardcourtroom bench, I briefly wondered whetherthe jury might fall for this version of theclassic FUD strategy and be so fearful andconfused as to find for the plaintiffs.

It turned out that there was no cause for

concern. Michael Tiemann, Red Hats vicepresident of open source affairs, explainedthe fundamentals of open source so as tomake them clear, and even inspiring. Heexplained that open source software is aboutvoluntary collaboration, not involuntaryexpropriation. He also made plain thatRed Hats legitimate criticisms of the existing

patent system in no way shows a proclivityto infringe patents or indifference to patentclaims, and that Red Hat respects and abidesby the law.

Our side took the opposite approach fromthe plaintiffs, basing our case on facts andevidence, rather than emotion and confusion.Our experts carefully showed that our prod-ucts were noninfringing and demonstratedspecific examples of prior art. In the end,the jury saw through and quickly rejectedplaintiffs FUD. The jurors took a bit more

than two hours to find every one of 23 issuesin favor of Red Hat and Novell.

We learned many things from this experi-ence, but Ill note just three here. We nowknow for certain that those in the businessof bringing software patent lawsuits are notinvincible, even in the supposedly patent-friendly jurisdiction of the Eastern District of

Texas. We know that Texas juries are willingto reject bogus infringement claims andinvalidate bad software patents. And weknow that attacks on open source based onFUD will not stand up when subjected to thelight of truth.


20/54


Over the last eight years, Pamela Jones,known as PJ, wrote volumes at Groklaw1first as a blog about the holes in SCOsclaims, then increasingly as a place for widercommentary on the legal issues facing Linuxand open source. To summarize the sitesmission statement2, Groklaw was a full legalnews resource, acknowledged and used

by all the parties, including SCO. But it wasalso a communitya place for open sourcebelievers to gather, learn, and share.

Last month PJ announced that becauseSCO as we knew it is no more, she wouldstop publishing new articles today3, May 16,Groklaws anniversary. Now shes handingthe reins over to Mark Webbink4, former

general counsel at Red Hat, law professor,and board member at the Software FreedomLaw Center, to create Groklaw 2.0.

Heres what she had to say about Groklawspast and her future.

What inspired you to start Groklaw?

Did you anticipate the audience it cameto appreciate?

When I started, I was literally just practic-ing for a job interview. I had no knowledgeof the Internet, obviously, so I didnt knowthe whole world could see what I was doing.When people showed up, it was a shock, andthe numbersit was hundreds of people allof a sudden, then thousands, until we finally

INTERVIEW: PJ ON THE

BEGINNING, ENDING,

AND FUTURE OF

GROKLAWRuth Suehle(originally published May 2011)


21/54

19Interview: PJ on the beginning, ending and future of Groklaw

had to move to larger quarters. After I gotmore used to it, it was exciting too. Becausewhen I saw the level of technical knowledgemy readers had and how much they wanted

to learn how the legal process works, I real-ized what it could mean, what we could do,if I could learn to ride the wave.

Where do you think Groklaw has been most

informative and influential?

Its hard to praise oneself without feelingidiotic. But as a group, what we showed isthat if the FOSS community gets behind an

effort to do legal research, no single law firmcan beat them. The community we built livedcomputer history. The gray beards are stillamong us, after all. So we have UNIX guysand we have Linux guys, the very peoplewhose code was being fought over by corpo-rate interests.

So we were a voice, a way for the communityto point out what was not true, and theycould point to the evidence that it was nottrue. Law firms dont have that, and youcould see the difference. They might havean expert, but that person cant competewith a community like Groklaws. Theyd filea document with the court and within hoursthe community would have taken it apart

and shredded it, and they were right, overand over and over.

What I am most proud of is our trial cover-age in SCO v. Novell, the jury trial. That andbeing the ones to first publish the previouslysealed settlement agreement from the BSDilitigation. Im proud of the fact that the com-munity we built is still strong, still ready todo whatever needs doing. Building and main-taining a community isnt as easy as it looks.Over the years, some thought they could doa better Groklaw, and they did try, but noneof them continued or ever really took off.

If you were starting Groklaw again today,

with the benefit of the experience youvehad, would you do anything differently?

I was naive in the beginning. I didnt know

people as venal as I was about to be writingabout. And I didnt know anyone personally,except for one relative, who lied without anyapparent pangs of conscience. So at first,whoever showed up to help was accepted atface value. Later, I realized that some wereoperatives working to destroy from within.It was a sad and creepy lesson to have to

learn. If I were starting it up now, I wouldfactor that knowledge into every part ofwhat I built.

Why did you decide to discontinue workingon Groklaw?

Ill still be working on it, just not doing ar-ticles. I want to finish the Comes v. Microsoftexhibit collection and fix some other loosestrings, so the work stands the test of timeand is truly useful to historians and lawyers.

I cant do that and write articles every day.And I have a number of personal and otherwork projects that I shoved to the backburner in order to do Groklaw, and now thatthe emergency for Linux is handled, its time

to prioritize in a more normal way. We won,the emergency is over, and I get to relax abit now.

So that is part of it. But the most importantconsideration was this: I was born to writeGroklaw, about SCO and the Linux kernel andcopyright litigation. But the battlefield nowhas shifted to mobiles and patents. I thought

seriously about that, and I recognized that Iam not the right person to take the lead onthat. I always hated patent law, and nothingIve seen in the last 8 years has altered myfeelings. I hate software patents with a pas-sion, I think they are destroying innovationin the US, and that they particularly threatenFOSS, the open development model being


22/54


opposed to patents. I think software andpatents need to get a divorce.

I consider that a serious enough matter thatI thought modesty needed to inform me to

stop, that others could fill the role and wouldif I did. Then when I announced I would stop,I was flooded with requests to find someoneto continue, and I realized the communitywas right. It was irresponsible if I didnt tryto maintain the community, their skills, inone place. And happily, we found someone.I think Groklaw will end up more impor-

tant than its been, actually, because MarkWebbink is lawyer, a FOSS lawyer, and a lawprofessor. With him taking the lead, and hislaw students and we hope eventuallyothers at other law schoolsjoining thecommunity, it can grow in the direction thatis needed now. They can explain the law, andthe community at Groklaw can help themunderstand the tech. Its what Groklaw is for,what I dreamed it should bea place wherethe two communities can teach each other,so they can together hopefully help judges tounderstand the tech so they can reach betterdecisions, ones based on technical realities.So this is organic, part of what Groklaw issupposed to be, just the next step.

Part of Groklaws success was realizing thatwe could contribute just as we are, withouttrying to be more than we were. But thatmeans also remaining modest and aware ofwhat we were not qualified to do. I alwayssaid the only legal advice I ever give is, Askyour lawyer. Well, now Groklaw is going tofollow that advice and get a lawyer. Its anatural progression. And its the right time,given Microsofts rather obvious strategy ofusing patents against GNU/Linux.

How would you describe the relationship

between Groklaw and open source?

Groklaw is an application of Open Sourceideas to legal research. But Open Source

doesnt mean a free for all. With the Linuxkernel, Linus and his maintainers rule ulti-mately. Everyone can contribute freely, butas you go up the chain, there is an edito-

rial process, so that the best get the mostresponsibility and the final say belongs toLinus. Same with Groklaw.

After there were threats and harassment,we had to be less open to the world aboutcertain things, to protect everyone. Thatsnot something open source softwareprojects have to deal with, so the differences

that sometimes people comment on are dueto that distinguishing factor. For example,at first Id ask people if they wanted publiccredit for their work. Lots did. Later, nobodydid, but they still worked just as hard. So,internally we knew who deserved the creditand who should get more responsibility, butoutside it was not apparent. Like a pool thatlooks peaceful on the surface but belowthere are currents flowing in all kinds ofways at once. Groklaw is like that. And itsproof to me that people dont volunteer forsuch projects out of ambition or a desire forcredit. The community continued to work

just as hard as before, and for absolutelynothing in return, just to make a difference ifwe could. Kind of like you see in communities

threatened by a flood and they all go out andfill bags with sand.

I sometimes say that if the whole world waslike the FOSS community, everything wouldbe better. And I mean it.

What do you think are the lessons thatGroklaw holds for open source and

collaborative communications effortsin other areas?

That it works just as well for legal researchas for software development, so long as youhave an editorial process to decide what isaccepted and what isnt and as long as youapproach your particular task in a pragmatic


23/54

21Interview: PJ on the beginning, ending and future of Groklaw

way, recognizing that software develop-ment isnt like many other types of projects.But what is key is the ability to put togetherthousands of people all over the world and

get them to work unitedly toward a commongoal. Its a remarkable thing. I wouldnt havemissed it for anything in the world, and Illnever forget it. When Groklaw would winawards, Id always credit the group, andsometimes people would act like that wasjust pro forma. It was not. I certainly andabsolutely could never have done Groklawalone. There is a kind of dynamic to a largegroup that is as powerful as a tornado but ina positive waywhen you let people showinitiative and they send you their ideas andmaterials and evidence and personal experi-ence and let them try things. All you have todo is provide a little direction. Sometimes itworks, and sometimes it doesnt, but whenit works, you can change a little bit of the

world. Groklaw indubitably did.

Do you have any future projects,particularly relating to open source or

technology, in the works?

My fervent desire is to leave the limelightbehind and live a private life again. I alwayswanted that. Since I never planned for

Groklaw to become Groklaw, it was a mixedblessing when it happened. It was fun, itwas creatively exciting, and ultimately it wasfulfilling in a way that I cant even put intowords. Maybe this: I know something I didin this world actually mattered. Its quite afeeling. But as I said, it wasnt a plan, and Icertainly have never been ambitious, and Ididnt want anything from Groklaw exceptto be effective. Now that it is, Im happy and

satisfied. I never wanted to be somebodyand fame repels me, frankly, and Ive avoidedit. Now, I have an opportunity to go backto my previous personal life, happy in the

knowledge that we did what we set out todo. Ill be around in the sense that Ill be inthe background until I finish the transition,training the new people, and finishing up thepolishing of Groklaws records. Then, itll beme on my porch, waving at cars as they goby, and just living a relaxed and normal lifeagain. Ive never worked so hard in my life asI did on Groklaw, and I need, really need, torest up a bit.

1. www.groklaw.net/

2. www.groklaw.net/staticpages/indexph-p?page=20040923045054130

3. www.groklaw.net/article.php?sto-ry=20110409161444432

4. www.groklaw.net/article.php?sto-ry=20110515173831922


24/54

AN OPEN WORLD:

STORIES FROM THE


EDUCATION


25/54


26/54


27/54

25Student participation in open source projects (a professors perspective)

desire to be self-directed and to have controlover what they do.

So what else have I learned, as a professortrying to get more students involved in open

source? Lots!

Participation in open source definitelybenefits students. I have watched studentsgain invaluable professional knowledgeand experience, growing skills and formingprofessional networks through participationin open source. Many students are motivatedby participation in open source projects in

a way they arent in a traditional classroom.They have a better understanding of how theseemingly esoteric things theyve learned intheir courses matter.

Setting expectations is important. Expecta-tions are importantfor both the studentand for the open source community. Thedifferences in cultures identified above mustbe understood by both groups in order tosupport a successful collaboration. The ac-tual methods and manners of participation inthe project may look very different from theacademic and open source perspectives.

I can be more opportunistic. My preferredapproach is to plan things out well in ad-

vance. Talking to Mel made me realize thatthere were lots of opportunities that occurspontaneously. With little effort, I could takeadvantage of these opportunities if Im will-ing to alteror abandonmy plan.

For instance, with two days notice, Mel andI set up a Hack Share2where we invitedSebastian Dziallas3to come hack (live and

in-person) and teach students how topackage an application. I would not haveattempted this on my own, assuming thatI would need lead time to advertise, getresources, secure a locationall the details.However, Sebastians talk was very well at-tended and a huge success on a small scale.

Could I have gotten a larger attendance?Sure! But not in my window of opportunity.With little time to plan, the Hack Sharereached only a small number of people. But

if I refused to try because of the immediacyof the opportunity, the event might not haveoccurred at all. The trade-off is to reachfewer people in smaller ways, but with alarger number of experiences. The conversa-tions Ive had with Meland the success wehad with this quickly formed eventencour-age me to take advantage of opportunitiesthat arise.

Academia needs to be sure to give backto the open source community. One veryreal danger of student participation inopen source software development is thatstudents will learn from the community,gain from the community, and then notprovide anything back to that community.

This violates the open source way and couldeasily break up open source/academic col-laborations. In my opinion, the onus is onprofessors to find a way to provide somereturn value to the open source community.This value does not necessarily need to be inthe form of code, and could easily take theform of documentation, wiki gardening, orother needed tasks.

I believe that our efforts involving studentsin open source projects will pay off for theopen source communityin the long run .It may be many years before these benefitswill be reaped. I say this for several reasons.First, most students are focused primarilyon their degree and then on getting a job.

These are folks who are (rightly so) spendingmost of their energy on establishing careers.This means that for at least a year (perhapslonger) after graduation, these folks may nothave time to contribute to open source projects.


28/54


Second, I believe that students will carrythe banner for open source, but that it willtake time for the idea to spread. Rememberthat students are not professionals and

they are learning how to participate openly,in addition to the material in all their otherclasses. They typically have a much longerentry timeframe into open source than anexperienced developer.

Lastly, academia moves at a snails pacecompared to the open source world. It willtake time for professors to understand the

opportunities offeredand the social obli-gations necessitatedby involving studentsin open source. And it will take them evenlonger to change their own classes to includeopen source; longer still to have open sourceintegrated across a curriculum.

These observations have both positive andnegative repercussions for the open source

community. The bad news is that there is notlikely to be a huge influx of new open sourcedevelopersgraduating college studentsfamiliar with the open source wayin thenear future. This is compounded by the factthat the number of computing students hasnot yet recovered from the steep decline innumbers that occurred in the 2000s.

The good news is that there is likely to bea trickle of these university-taught devel-opers and that this small stream is likely tocontinue for many years. It is my hope thatthe stream will grow as word spreads and asmore professors adopt approaches involvingstudents in open source projects.

One significant advantage in our efforts tomake open source more prevalent on collegecampuses? The already-growing awareness

of open source within the computing studentpopulation and beyond. Students are excitedby participating in open source, no matterhow its introduced. Hopefully this excite-

ment will catch fire in academiain theclassrooms and beyond.

1. www.opensource.com/users/mchua

2. http://opensource.com/education/10/11/open-source-and-student-engagement-explained-5-minutes

3. www.opensource.com/users/sdziallas


29/54

27Three unspoken blockers that prevent professors from teaching open source community...

One of the hardest things about trying tobridge two worldsfor instance, opensource communities and academic institu-tionsis all the stuff you dont hear on adaily basis when youre working remotely.Sometimes it takes several rounds of garlicbread and pasta for people to begin articu-lating whats blocking them from teachingtheir students how to participate in FOSScommunities. Sebastian Dziallas1and I satdown last weekend at the 2010 Frontiersin Education conference2with a group of

professors from the Teaching Open Sourcecommunity3.What are the biggest blockersthat youre facing in doing this, we asked,

that people in the open source world justdont know about or understand? Here aretheir answers.

Blocker #1: Intellectual property policies,aka No, you cant release that under anopen license.

At some schools, if you make it on campus,for campus, or with resources from campus,

THREE UNSPOKEN

BLOCKERS THAT

PREVENT PROFESSORS

FROM TEACHING OPEN

SOURCE COMMUNITY

PARTICIPATIONMel Chua (originally published November 2010)


30/54


guess who owns it? Yep: campus. One waycolleges and universities make money is

technology transfer, a form of intellectualserfhoodif youre a professor, a student,or a lab, you get resources (students, classes,space, equipment) from the school, but allthe IP you produce is owned by the school,so the school takes care of licensing that IPout to companies that want to use it... andkeeps the cash.

If youre a school, this arrangement worksout in your favor, so you put policies in placespecifically preventing students and profes-

sors from giving away their schoolwork forfree, because... well, thats how you makemoney. The concept of open licensing as abenefit (free marketing!) to the universityinstead of a drain (giving away precious IPwed otherwise sell at a profit!) is new tomany places, and when youre trying to geta project started for a ten-week class, youcant afford to spend all ten weeks patiently

educating university administration aboutthe benefits of licensing (while you simulta-neously try to learn data structures in Java).

So thats one bug.

Blocker #2: Student privacy, aka Weregoing to make your students fill out formsnow before they can release their workfor class.

Even if professors (and students) think itwould be beneficial for student work andprofessor feedback on that work to be outin the open where more people can see andcomment on and benefit from it, clearancehas to be specifically sought because of fed-eral regulations like the United States FamilyEducational Rights and Privacy Act (FERPA).These are designed to keep sensitive data

about students (read: grades) under theirown control. But its a fine line to walkcan you require people to upload gradedclasswork to a public server? Can you do yourcomments and evaluations there? Can yourequire them to list their names? To workand interact with a community they may not

want to work with (for instance, if your classis a requirement, and students arent therevoluntarily)?

Different institutions have different policies,

and some professors may not have the time,the legal expertise, the political capital, orthe ability to take the risk and step forth forthe advocacy this might take at their particu-lar school. When youre at a school to teachstudents, you want to spend time teachingthem, not responding to letters from admin-istrators concerned about families complain-ing that youre broadcasting their childrens

private data.Blocker #3: IT support, or the lack thereof.

People from the open source world are usedto the following workflow when they wantto show others a new piece of (open source)software:

1. Go to the computer sitting on your desk.

2. Download and install the software.3. Email your friend the link to your web server.

Professors can do the same thing, but oncethey want to make that resource available tothe students in their classes, they may haveto first:

1. Ask IT for an internally hosted box.

2. Wait a while.

3. Try asking, When can my TA and I havean account on a server? Any server! Anyserver at all!

4. Offer, Yes, yes, Ill administer it myself (inmy nonexistent free time).

5. Fill out more forms.

6. Worry that half the semester isalready over.

7. Wonder how much longer this is goingto take.

8. ...and so on.


31/54

29Three unspoken blockers that prevent professors from teaching open source community...

1. www.opensource.com/users/sdziallas

2. www.fie-conference.org/fie2010/

3. www.teachingopensource.org/

Even if you get ITs permission to try outsomething, or persuade your students totry out some open source applications ontheir own, the question then becomes oneof support. If your students install Linux and

tinker around and crash their computers, ITisnt going to fix it. Students know this andoften dont want to take the risk. If they do,and things break, theyll come to youandso in addition to being a professor, you nowget to provide technical support for yourentire class for applications you are probablynot familiar with debugging.

How can we help?Remember, these comments came fromprofessors who have already fought throughwhatever they needed to figure out in orderto start getting their students involved.These are the people who are alreadyclearing out these blockersoften workingfor several years to even be able to startto teach their students about FOSS. These

professors are still few in number, and thefirst of their kind, oftentimes standing asthe only faculty member in their institutionwho doesnt think the idea of teaching FOSSis crazy. These people are our allies. Howcan we help them get past the communityparticipation bugs that are stumping them?

Thanks to Heidi Ellis (Western New England

College), Matthew Burke (George Washing-ton University), Clif Kussmaul (MuhlenbergCollege), Greg Hislop (Drexel University),Mihaela Sabin (University of New Hampshire),and Steve Jacobs (Rochester Institute ofTechnology)for the discussion that led tothese notes, and to Sebastian Dziallas (OlinCollege) for helping me write them up intothis article.


32/54

AN OPEN WORLD:

STORIES FROM THE


HEALTH


33/54

31Join The M RevolutionGet your tools

JOIN THE M REVOLUTION

GET YOUR TOOLSLuis Ibanez (originally published March 2012)

The M programming language is also knownas MUMPS. Which stands for MassachusettsGeneral Hospital Utility Multi-ProgrammingSystem. Read my earlier post1introducingthe multi-user, strongly imperative languagedesigned to manipulate and control massivedatabases. Then get started using it withthis tutorial.

Two main software environments areavailable today for programming in M:

Intersystems Cach2

FIS GT.M3

You can download an evaluation version ofIntersystems Cach4, but because FIS GT.Mis free and open source, we will use it hereas the reference system for this tutorial.

The M language has a well defined set ofstandards:

ISO/IEC 11756:19995

ISO/IEC 15851:19996

We will stick to the M-standard in the ex-ercises of this tutorial, therefore the sourcecode examples should work in both GT.Mand Cach environments.

Lets focus now on installing GT.M andgetting it to work in your favorite Linuxinstallation.

Every tool is a weaponif you hold it right.

Ani DiFranco


34/54


Step 1: Download and install GT.M

Download and install GT.M:

$ wgethttp://download.sourceforge.net/project/fis-gtm/GT.M%20Installer/v0.11/gtminstall 7

$ chmod +x gtminstall

$ sudo ./gtminstall utf8 default

Work is in progress to create Debianpackages for GT.M (debian-med fis-gtm)8,and they should be available soon. In themeantime, the instructions above are themost straightforward way to install GT.Min your Linux environment. Note that thisinstallation will use easy defaults. Such anenvironment will be good for trying out GT.Mand for running through the exercises of thistutorial, but it may not be good enough for aproduction system. Consider this installationa safe sandbox for learning M.

The executables of the installation will, bydefault, go to one of the following direc-tories (depending on whether you are in a32-bit or 64-bit architecture):

/usr/lib/fis-gtm/V5.5-000_x86/

/usr/lib/fis-gtm/V5.5-000_x86_64/

Now we set up the environment variables forGT.M by sourcing the gtmprofile file.

From your shell, do the following:

$ source /usr/lib/fis-gtm/

V5.5-000_x86/gtmprole

You will see output similar to:

%GDE-I-GDUSEDEFS, Using defaults

for Global Directory

/home/ibanez/.fis-gtm/V5.5-000_

x86_64/g/gtm.gld

GDE>

%GDE-I-EXECOM, Executing

command file /usr/lib/fis-gtm/

V5.5-000_x86_64/gdedefaults

GDE>

%GDE-I-VERIFY, Verification OK

%GDE-I-GDCREATE, Creating Global

Directory file

/home/ibanez/.fis-gtm/V5.5-000_

x86_64/g/gtm.gld

Created file /home/ibanez/.fis-gtm/

V5.5-000_x86_64/g/gtm.dat

%GTM-I-JNLCREATE, Journal file /

home/ibanez/.fis-gtm/V5.5-000_

x86_64/g/gtm.mjlcreated for

region DEFAULT with

BEFORE_IMAGES

%GTM-I-JNLSTATE, Journaling state

for region DEFAULT is now ON

For the long term, it is convenient to do thisfrom the initialization file of your favoriteshell. For example, in bash, add the follow-

ing lines to your $HOME/.bashrc file:

# Set up GT.M environment.

source /usr/lib/fis-gtm/

V5.5-000_x86/gtmprole


35/54


This adds a set of GT.M-related variablesto your environment, and also adds theGT.M executables to your PATH. If you are

curious, you may want to take a look atthose changes by doing the following in theprompt of your bash shell:

$ env | grep gtm

Now you can run GT.M for the first time bysimply typing gtm at the shell prompt.

$ gtm

This should open the GT.M prompt:

GTM>

At this point you can type a couple of verifi-cation commands. For example:

GTM>write $zversion

GT.M V5.5-000 Linux x86

GTM>halt

The intrinsic special variable $zversion9returns the version of the installed Menvironment. The halt10command stops thegtm interpreter and returns control to theoperating system, so you will be back atyour shells prompt.

The initialization process creates a localinstallation in your home directory under:

$HOME/.fis-gtm

with the subdirectories:

$HOME/.fis-gtm/r

$HOME/.fis-gtm/V5.5-000_x86

(if in a 32bits architecture)

$HOME/.fis-gtm/V5.5-000_x86_64

(if in a 64bits architecture)

As we write code examples, these are the

directories where the code will go.This is a good point to note that M/MUMPSis a combination of a programming languageand a database (as was kindly pointed outby one of the first commenters to our pre-vious post)11. We will try to be more explicitgoing forwards when we are referring to thelanguage versus when we are referring to

the database.Step 2: Testing the installation

We can now write a hello world program.

First, set the path to your favorite editor inthe EDITOR environment variable of yourshell. For example in bash:

EDITOR=/usr/bin/emacs

or

EDITOR=/usr/bin/gvim

Then from the same shell, invoke gtm, and atthe prompt, request to edit the Hello.m file:

GTM>ZEDIT Hello.m

This should open the editor program thatyou just set up in the EDITOR environment


36/54


variable, and now you can type in it thefollowing M code:

MYLABEL ; This is a comment

WRITE !,Hello World

QUIT

Note that the second two lines leave oneblank space in the first column, while thefirst line (containing a label) starts in the

first column.Then save the file and quit the editor. Onceback at the gtm prompt, type:

GTM>ZLINK Hello

and execute the program by using theDO12command:

GTM>DO MYLABEL^Hello

Hello World

Lets now edit the program again by typing:

GTM>ZEDIT Hello.m

and once in the editor, lets insertanother line:

MYLABEL ; This is a comment

WRITE !,Hello World

WRITE !,$HOROLOG

QUIT

Then save the file and link it again withthe command:

GTM>ZLINK Hello

It is important to call ZLINK12every time thatyour modify the source code, since it willrecompile it and will replace the previouscode in the current environment. Now youcan execute the new version with:

GTM>DO MYLABEL^HelloHello World62520,56765

The $HOROLOG13special variable returnsthe date and time as a string value speci-fying the number of days since December31, 1840 and the number of seconds sincemidnight of the current day. (Read why thatdate was chosen.)14

Step 3: Looking under the hood

You may find it interesting to see where thesource code and compiled versions of your

routines are going. Take a look atthe directories:

$HOME/.fis-gtm/

V5.5-000_x86_64/r/

$HOME/.fis-gtm/

V5.5-000_x86_64/o/

where you will find the files:

$HOME/.fis-gtm/

V5.5-000_x86_64/r/Hello.m

$HOME/.fis-gtm/

V5.5-000_x86_64/o/Hello.o


37/54


1. www.opensource.com/health/12/2/join-m-revolution

2. www.intersystems.com/cache/index.html

3. www.fis-gtm.com/

4. www.intersystems.com/cache/downloads/index.html%20

5 www.iso.org/iso/iso_catalogue/catalogue_tc/

catalogue_detail.htm?csnumber=29268

6 www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29269

7 download.sourceforge.net/project/fis-gtm/GT.M%20Installer/v0.11/gtminstall

8 www.debian-med.debian.net/tasks/his.fr.html

9 www.tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/ch08s49.html


11 www.opensource.com/health/12/2/join-m-revo-lution#comment-9013


13 www.tinco.pair.com/bhaskar/gtm/doc/books/pg/

UNIX_manual/ch08s05.html14 www.en.wikipedia.org/wiki/MUMPS#

Epoch_choice

15 www.tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/index.html

16 www.vistaexpertise.net/docs/pocket_guide.pdf

Acknowledgments

Many thanks to K.S. Bhaskar (DevelopmentDirector at Fidelity National InformationServices, Inc.) for his guidance on fis-gtm

and for providing the large majority of thematerials presented in this tutorial. All errorsthat may have slipped above, of course, aremine alone.

References

The complete reference to the M language isavailable at:

www.tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/index.html 15

The pocket guide to MUMPS is available at:

www.vistaexpertise.net/docs/pocket_guide.pdf16


38/54


OPEN SOURCE

CANCER RESEARCHLori Mehen (originally published December 2011)

When it comes to treating, curing, and pre-venting cancer, modern medicine has largelyfailed. You could argue that cancer is far toocomplicated to unravel in the few milleniawe have been documenting it. Or that the

billions we spend annually on research is fartoo little. Established incentives and policiesthat perpetuate research silos certainlyseem to slow success.

Medical researchers have been trained in aprofessional culture where secrecy reigns,where they must protect their own interests.The dominant culture discourages sharing

research findings and collaborating onprojects. It has become more important toprotect vested interests than to take advan-tage of the huge collaborative network thatis available in academia.

This mode of thinking is a bitter pill toswallow for the quarter of our populationthat will die of cancer. According to theWorld Health Organization1, one in every fourdeaths is attributable to cancer.

What would happen if cancer researcherswere able to adopt an open and collabora-tive approach like the one that hasfor thelast two decadesrevolutionized softwaredevelopment? What if cancer research couldbe open source?

Linux has been successful because a large

group of people recognized a need andagreed on a process for meeting that need.The brilliance of the open source approach isin the sheer amount of participating brain-power. The open source community showsthat the collective intelligence of a networkis greater than any single contributor.


39/54

37Open source cancer research

While the term is attributed to softwaredevelopment, the idea is not. In fact, somemedical research does use this method-ology in the same way that Linus Torvalds

and others develop open source operatingsystems. The Human Genome Project2,for example, very successfully distributedgene-mapping in efforts to speed up thesequencing of the genome. The HGP teamspublished their data openly, on the Internet.

More recently, a team of Harvard3research-ers discovered the power of distributed

research. A team led by Jay Bradner4

at theDana Farber Cancer Institute5discovered asmall-molecule inhibitor that showed prom-ise in its ability to interrupt the aggressivegrowth of cancer cells. The small-moleculeinhibitor, called JQ1after Jun Qi, thechemist who made the discoveryworksby suppressing a protein (bromo-

domain-containing 4, or Brd4) necessaryfor the expression of the Myc regulatorgene. It is a mutated Myc gene that isbelieved to be at the root of many can-cers. Without Brd4, Myc remains inactive.Inhibiting Myc could be part of the key tosuccessful cancer treatments.

With the cells from an affected patient,

Bradners group successfully grew thecancer in mice and discovered that themice with the cancer who received thecompound lived, while the mice with thecancer who didnt receive the compoundrapidly perished.

Instead of operating in secrecy and guardingtheir work, Bradners group shared it. They

simply started mailing it to friends. Theysent it to Oxford crystallographers, who sentback an informative picture that helped Dr.Bradners team to understand better how thesmall-molecule inhibitor works so potentlyagainst Brd4.

They mailed samples to 40 labs in the USand 30 more in Europe, encouraging theselabs to use it, build upon it, and sharetheir findings in return. As a result of this

open source approach, Dr Bradners teamhas learnedin less than a yearthatJQ1 small-molecule inhibitor preventsthe growth of leukemia, making affectedcells behave like normal white blood cells.Another group reported back that multiplemyeloma cells respond dramatically toJQ1. Still another found that the inhibitorprevents adipose cells from storing fat, thuspreventing fatty liver disease.

Bradner has published his findings. Hehas released the chemical identity of thecompound, told researchers how to make it,and even offered to provide free samples toanyone in the medical research community.(If youre a researcher whod like a sample

of the JQ1 molecule, you can even contactBradners Lab via twitter @jaybradner6.)

Bradner feels his early successes are due notonly to the science, but also to the strategy.Using an open source approach, sharingthe information about this molecule, andcrowd-sourcing the research and the testingillustrates the opportunities that an open

methodology can bring to the difficult chal-lenges of medical research and prototypedrug discovery.

In his recently released TED talk video,Dr. Bradner explains that he firmly believesthat making a drug prototype freely availableamong researchers will help accelerate thedelivery of effective cancer drugs to

affected patients.With more practiceand more familiaritywith each other and this kind of collabora-tive researchscientists can break large,complex, time-expensive projects intosmaller, achievable portions. By spreading


40/54


1. http://www.who.int/mediacentre/news/releas-es/2003/pr27/en/

2. www.ornl.gov/sci/techresources/Human_Ge-nome/project/about.shtml

3. www.hms.harvard.edu/hms/home.asp

4. www.bradner.dfci.harvard.edu /

5. www.dana-farber.org/

6. https://twitter.com/jaybradner

out those small tasks among many groups,much more work can be accomplished in avastly reduced amount of time.

Using the old research models, Bradners

team might have learned that JQ1 affectsAML cells in the first year. But it might havebeen next year before they got to leukemia,and years after that before they realized italso could affect fatty liver. How many yearsdo you think the old approach adds to thedevelopment of drugs we need today?

It is time to seriously consider a different

model for scientific researchone that di-rectly engages and benefits society, encour-ages open access and the free exchange ofscientific information. The benefit to patientswould be enormous.


41/54

39History of open source in government

GOVERNMENT

AN OPEN WORLD:

STORIES FROM THE



42/54


43/54


Governments use of open source softwareas we know it today.

For the next several years, advocates in theprivate sector and cautious staff in govern-

ment began to engage the questions thatstill confront open source today: Is it ready?Is it secure? How do we use it? In 1999,Mitch Stoltz of NetAction wrote the firstpersuasive essay on the topic, The Casefor Government Promotion of Open SourceSoftware3.Stoltz invokes many argumentsthat are still being used today: lower cost,

increased flexibility, and better security.That same year, the Presidents NationalCoordinator for Security, InfrastructureProtection, and Counter-Terrorism conveneda multi-agency working group to produceOpen Source Code and the Security ofFederal Systems. That report is the firstofficial study of open source by the federal

government.While at the Air Command and Staff College,Major Seiferth returns to our history again,this time publishing a research report on thepotential benefits of open source specificallyin the DOD. Seiferth notes ironically that theUS Government is at once reluctant to useopen source, and a great creator of open

source projects4

:Within the Department of Defense, the National

Laboratories and Defense Advanced Research

Agency have been the most visible users and

producers of open licensed systems. Theyve

released such advances as the original firewall

and network security toolkits. As a more recent

example, within the last year the National Air and

Space Agency has debuted several inexpen-

sive supercomputers. Open licensed operating

systems and applications allowed the scaling of

inexpensive pentium-based machines into an in-

tegrated hardware/software system. In addition

to being inexpensive, these machines are among

the most powerful available.

Seiferth, like Stoltz, makes a number offamiliar arguments for open source, but hisgreatest insight is that open source is Com-mercial Off-the-Shelf (COTS) software. This

is significant, because it means that opensource would be able to use the existingpolicy and regulations that had already beencreated for software more generally, ratherthan being treated as a special case andthus hampering its adoption. This will laterbecome the explicit policy of the Office ofManagement and Budget, as well as theDepartment of Defense.

The very next year brings an explosion ofopen source activity in government. In theprivate sector, IBM announced that they areinvesting one billion dollars5in the Linuxproject. The Open Source Software Institute6was founded to aid the adoption of opensource in the Federal government.

Meanwhile, government adoption continuesapace. We begin to see the procurement ap-paratus wrestle with open source licensingin procurements. The US Air Force Scien-tific Advisory Boards Ensuring SuccessfulImplementation of Commercial Items in AirForce Systems7is the first procurementguidance to explicitly mention open source.

Some agencies arent waiting, though. TheNational Security Agency to the aston-ishment of its peers and the open sourcecommunity releases SELinux8, whichprovided a set of strong security controls tothe Linux operating system. In doing so, theNSA was taking technology that had beenuseful to a very small set of customers, and

was therefore very expensive, and madeit freely available to the general public. In-novation quickened, the software improved,and SELinux is still used in Linux today. Mostrecently, SELinux was ported to the Androidsystem9, where it provides mobile phone us-


44/54


ers protections against hostile applications.This wasnt the first time the US governmenthas released software, but it made head-lines because it was an implicit endorsement

of the open source process by arguably themost security-conscious intelligence agency.

This flurry of activity continues into 2001,with MITRE releasing Making the Busi-ness Case for Open Source Software10.This document, the most comprehensivetreatment of open source to that point, waspublished as part of the larger Open Source

Software in Military Systems study whichthe US Army had commissioned from MITRE.The report concludes: Open source will ben-efit the government by improving interoper-ability, long term access to data, and theability to incorporate new technology. Here,we see the US Army, who is later to becomeone of the largest open source users in the

world, taking its first exploratory steps.The next major milestone is in 2003, withthe release of the Stenbit Memo11.On May28, the DOD CIO John Stenbit released thefirst DOD-wide guidance on open sourcesoftware, which implicitly permits its acqui-sition, development, and use. Meanwhile,the Army begins to deploy the Blue Force

Tracker, running on open source software,to over 80,000 tactical vehicles. Famously,General Nicholas Justice proclaims, Whenwe rolled into Baghdad, we did it usingopen source. Nine months later, in July of2004, the OMB issues a memo similar tothe Stenbit Memo that covers the govern-ment as a whole. At approximately thesame time, NASA releases the very popularWorld Wind12geospatial visualization projectunder the newly-minted NASA Open SourceAgreement13. Six months later, Red Hat, theworlds largest open source company at thetime, creates a US Government division14and

the first Government Open Source Confer-ence (GOSCON)15is held in Portland, Oregon.

In 2006, Sue Peyton, the Air Force AssistantSecretary of Defense for Acquisition, com-

missioned theOpen Technology Devel-opment Roadmap16,which goes beyondthe simple benefits of open source, anddescribes how it can be put to productiveuse in the context of the DODs Net-Centricdoctrine, which was in fashion at the time.This is the first effort to align the principlesof open source with an overall agency

strategy, demonstrating how savvy opensource advocates inside the governmenthave become.

In 2007, the US Navy commissioned Ray-theon, IBM, and Red Hat to add real-timefeatures to the Linux kernel17, which itrequired for the new destroyer it was build-ing. Significantly, the Navy ensured that the

software is released into the open sourcecommunity. Shortly thereafter, the US NavyCIO Robert Carey releases the Navy OpenSource Memo18, which explicitly classifiesopen source as COTS software. This is asignificant change in tone from the Stenbitmemo and OMB memos of 2004, which onlyimplicitly provide this same guidance.

Open source use subsequently explodes. BySeptember of 2008, the Microsoft-fundedOpen Source Census19was reporting thatopen source use in government was higherthan any other industry. The Federal OpenSource Alliances Federal Open Source Refer-endum20study reported that, 71% of agencyexecutives believed they could benefit from

open source and 58% said they were likelyto consider open source.

The Obama Administrations first act on tak-ing office was to issue the Open GovernmentMemo21, which articulated a general policy of


45/54


transparency, collaboration, and participa-tion. Subsequent agency initiatives prom-inently featured open source software as ameans to achieve those goals. Open source

policies began to pour out of governmentsat the federal, state and local level. NASA,in particular, made open source softwareand the open source development process acornerstone of their open government plan22.In the private sector, Open Source for Amer-ica23was founded. This coalition of industry,advocates, and individuals is meant to bea central resource for advocates of opensource software in government. That August,Macon Phillips, the White House New MediaDirector who would later release portionsof the software for whitehouse.gov, calledopen source the most concrete form ofcivic participation24.Clearly, open sourceand open government became inextricablyrelated.

In October of 2009, the DOD Open SourceMemo25is released by David Wennergren,the DOD CIO. This memo got headlinesaround the world, and remains the singlemost influential government policy docu-ment on open source today. The memo itselfis simple, and following the Navys declara-tion two years earlier, reminds procurement

officials that open source software is COTS.The appendices to the memo, however, gointo much more detail about the poten-tial advantages and risks of open sourcesoftware. The memo specifically encouragesthe DOD to take advantage of its ability tomodify software to suit a missions need.

Later in 2009, CENDI, an organization ofgovernment managers, issues a FAQ26oncopyright and open source to help agencylawyers understand open source licensingand the sometimes confusing intellectualproperty questions that they pose. A few

months later, for the first time since 2004,OMB refreshes its open source guidancewith the Technology Neutrality27memo,reminding agencies that competition in

software is important, and that they are for-bidden from discriminating against softwarebased on its development method. Once thismemo was published, most of the barriersto open source adoption had been dimin-ished or eliminated in the US government.

Unburdened, open source continued itsgrowth in 2011. Sue Peytons Open Technol-

ogy Development Roadmap from 2006 re-ceives a Lessons Learned28sequel, whichmakes recommendations to DOD programsinterested in releasing their own software.Eben Moglen, one of the most prominentopen source lawyers in the country, andhead of the Software Freedom Law Center29,releases Government Computer Software

Acquisition and the GNU General PublicLicense30,which explains the provisionsof that very popular open source licensein the context of government procure-ment regulations. Clearly, the governmentsunderstanding of open source had grownmore sophisticated since its first tentativeforays a decade before. A survey conductedby Lockheed Martin31at this time found that

69% of government contractors and 40%of federal agency respondents were alreadyusing open source. The survey also foundthat 66% of all respondents said that theywould be using more open source in thenext 12-18 months.

With this increased comfort, 2011 also sawthe release of more open source softwarefrom the government than ever before.The White House released portions of thecode for whitehouse.gov, the code for theFederal CIOs IT Dashboard, and the data.govplatform. At the end of 2011, the Federal


46/54


CIO announced a draft Shared First policy,which mandates re-use and sharing of ITresources amongst civilian agencies, andspecifically mentions that agencies should

collaborate on software development32

. Also,NASA releases code.nasa.gov, a landmarkproject to centralize all the source codereleased by NASA in one citizen-friendlyweb site33.

So we see the adoption of open source inthe Federal government as an evolution: thefirst furtive steps in the late 1990s and early

2000s, manifested in persuasive essays andstudies. From there, certain organizationslike NASA and the Army take leadershiproles in open source adoptions. From 2003to 2009, a series of policies institutionalizeits use throughout the government. By theclose of the first decade, the White House,NASA, the Office of Management and

Budget, and other agencies are not just us-ing open source, but creating and releasingopen source software of their own.

Did I miss a major event? A major code re-

lease? Let me know in the comments.

[This is a writeup I did as a companion to

the History of Open Source in Government

Timeline34

. Karl Fogel35

and I will be presentingmore findings36from the timeline at OSCON37

this year.]

1. www.catb.org/%7Eesr/writings/homesteading/cathedral-bazaar/

2. www.linuxgazette.net/issue19/hallways.html

3. www.netaction.org/opensrc/oss-report.html

4. www.dtic.mil/cgi-bin/GetTRDoc?Loca-tion=U2&doc=GetTRDoc.pdf&AD=ADA398898

5. www.news.cnet.com/2100-1001-249750.html

6. www.oss-institute.org/

7. www.dtic.mil/cgi-bin/GetTRDoc?Loca-tion=U2&doc=GetTRDoc.pdf&AD=ADA411926

8. www.selinuxproject.org/

9. www.selinuxproject.org/page/SEAndroid

10. www.mitre.org/work/tech_papers/tech_papers_01/kenwood_software/kenwood_software.pdf

11. www.terrybollinger.com/stenbitmemo/stenbitme-mo_png/index.html

12. www.worldwind.arc.nasa.gov/

13. www.opensource.gsfc.nasa.gov/nosa.php

14. www.gcn.com/articles/2005/01/21/red-hat-pushes-for-linux-in-federal-market.aspx

15. www.goscon.org/

16. www.acq.osd.mil/jctd/articles/OTDRoad

mapFinal.pdf

17. www-03.ibm.com/press/us/en/pressre-lease/21033.wss

18. www.doncio.navy.mil/ContentView.aspx?ID=312

19. www.lmaugustin.typepad.com/lma/2008/09/open-source-census-more-numbers-on-open-source-adoption.html

20. www.blogs.the451group.com/open-


47/54


source/2008/10/22/goscon-gives-government-good-open-source-ideas/

21. www.whitehouse.gov/the_press_office/Transpar-encyandOpenGovernment

22. www.nasa.gov/open/plan/

23. www.opensourceforamerica.org/

24. www.dailymotion.com/video/xgh1i3_obama-s-new-media-director-backs-open-source-govern-

ment_news25. dodcio.defense.gov/Portals/0/Documents/FOS-

S/2009OSS.pdf

26. www.cendi.gov/publications/09-1FAQ_Open-SourceSoftware_FINAL_110109.pdf

27. www.cio.gov/documents/Technology-Neutrality.pdf

28. dodcio.defense.gov/Portals/0/Documents/FOSS/

OTD-lessons-learned-military-signed.pdf

29. www.softwarefreedom.org/

30. www.acc.dau.mil/adl/en-US/475584/file/60698/OSS%20White%20Paper%2010-11.pdf

31. www.marketconnectionsinc.com/Reports/inter-section-of-open-source-and-the-cloud.html

32. www.cio.gov/documents/Shared_Services_Strategy.pdf

33. www.code.nasa.gov/

34. www.atechnologyjobisnoexcuse.com/2011/12/building-a-timeline-of-open-source-in-the-us-government/

35. www.red-bean.com/kfogel/

36. www.atechnologyjobisnoexcuse.com/event/oscon-2012/

37. www.oscon.com/


48/54


The battle for open standards in Europe

Today, people and groups around the world

are celebratingDocument Freedom Day1. Thisis an international day to raise awareness ofOpen Standards and free document formats.As the event takes place for the third time,the previous focus on the OpenDocumentFormat2(ODF) is broadening to include otherfree formats such as Ogg Vo