CSE350 Software Design and Engineering

1. CSE350 Software Design and Engineering University of Pennsylvania http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 March 5th, 2002

2. Administrative • Homework #2 due today • How did people do with it? • Homework #3 assigned Thursday (I am still testing a few details, so not today) • Have people been doing the readings? • Topic today: Free Software Foundation

3. History • RMS - hacker at MIT AI Lab • Really liked atmosphere • Contributed software such as “emacs” – editor macros (for early editor, “teco”) • Several events: Symbolics, AT&T “commercialization of UNIX” • Result-> GNU Manifesto

4. What is the GNU Manifesto? • Mid-80s. Circulated on pre-Web USENET and also available via Internet FTP. • Principled argument for software community versus commercial software • A “call to arms” for those similarly inclined • Crystallize Love vs. Money distinction…

5. Structure • Foundation (FSF) – a charity to which people donate machines, money, software, time • Some people work for FSF, depending of course on donation level • $$ also from sales of distribution, manuals, etc. • Incentive for machines: early ports

6. Software engineering • Distributed. Work over network • Some programmers at FSF • Others: meet as needed. • Take advantage of UNIX modularity: except for kernel, largely tools / componentware • RMS projectmeister; periodic releases (I wonder if this is an artifact of physical distributions?)

7. Intellectual property • A major distinction of FSF software is the so-called “copyleft” – the GNU public license (GPL) • Everybody is permitted to redistribute or modify software, but • No distributor allowed to restrict its redistribution • Use GPLed software, must GPL it too. • Very interesting consequences…

8. Effects of GPL • Using “emacs” doesn’t GPL result • Using “emacs” code base does • Since early GPLed software was system software (emacs, gcc, gdb), no big deal • However, many companies which create software for $$ do not want GPLed software used at it “contaminates” their software – restricting their right to sell it • Intellectual property value (e.g., of startup)?

9. Successes of project • GNU emacs (I’ve used for ~20 years…) • gcc – manufacturers support it – “good enough” • Gdb, flex, bison • Text tools: groff, gpic, geqn, grefer • Community: these tools continue evolving • Linux can be thought of as emerging from project GNU (Linux thinks not, tho…..!)

10. Failures of project • Never got a kernel working (this was called the “HURD”). Linux can be viewed as filling this hole, but not engineered by RMS/FSF • I view GPL as a failure. In its own way, it enforces someone’s perspective over how you use the software. BSD license makes no moralistic judgements.

11. Lessons for S.E. • Distributed programmers can be successful • Voluntary projects can produce software at least as good as paid programmers • As Raymond notes in C&B, debugging is distributed – “many eyes” hypothesis • Volunteers often extremely dedicated

12. Summary • Major advance in understanding how to build software: UNIX + hackers + net • Ongoing – it’s not over • Weird political overtones • Volunteers only work on what they’re iinterested in; tend to be “systems” things rather than applications – hence “ease of use” whinge