An update, a project, a new book

I apologize for this post coming a week later than I’d planned! To be honest, life happened and I forgot I’d left you hanging until I got an email about a reader’s comment on it. Sorry about that!

No more suspense, then. Saturday’s event was a complete success! We didn’t have all seventy kids, though. We had thirty-five or so again, and since we’d scheduled for seventy, they were a lot more spaced-out. It was a lot more laid-back than the day before (when we’d scheduled to pack the house), and let us work with smaller classes. Which, as any teacher will tell you, is an easier crowd to handle.

This time, we also handed out live Linux CDs with mass-printed disclaimers on them about not installing on the host computer, etc etc, disclaimer of warranty/responsibility/legal cya stuff. We also passed out slips with the URLs of my FAQ and the GitHub where the game I used lives. (I’ve been meaning to write some decent non-techie documentation for how to use that thing…)

I had originally volunteered to be part of the Hour of Code portion of the event on Saturday, rather than the Linux part, but stuff got a little mixed up. The teacher who was going to take the Linux event hadn’t looked at the Hour of Code activities for a year or two and hadn’t realized that it had changed; it now looks like Scratch or Alice, not a text-based activity like she’d thought. She’d planned on letting the kids play around with Scratch (because it’s a good intro to code, which is why HoC uses a similar system) on their Linux live CDs.

When she emailed me with her plans a day or so before her event, I didn’t connect the dots immediately–it took me a few hours before I emailed back to warn her that she had a duplicate activity on her hands, and by then it was rather late. She showed up on Saturday as we were starting to prep the Linux room (I was kind of early and was helping another teacher who had been in the building for a while). I warned her again about her duplicate and she pulled up a computer to look at the HoC activity. But before she could really panic, I reminded her again that I had a different setup that I’d already used, and which had worked well. So I swapped places with another volunteer who was going to help in the Linux room (he went to HoC instead) and kind of took over working my system.

And that’s how I ended up mostly in charge of that event again. Combined with the Raspberry Pi she’d brought, I feel it’s safe to say it was a really good experience for everyone involved.

Mind, this teacher is totally competent and a great teacher–she’s no newbie, she just happened to be relying on old info and I just happened to have something good up my sleeve. I got to squeeze more use out of my script game, and I earned major brownie points with someone I respect. 😉

As the participants fiddled with the game, I stood up and gave a little background info about Linux and the open-source world. I’m actually a decent speaker, believe it or not, when I’m speaking on something I know well. I’m still a much better writer than speaker, but I’m reasonably good at giving impromptu lectures if I know the subject matter. I read audiences fairly well, and though I have plenty of other fears and self-doubts, public speaking isn’t really one of them. (What I’m actually awful at is video. I can’t read a camera. It’s not a good audience.)

The people liked my game so much. A good number of them thought it was funny–one of the older girls got to the part about forfeiting your firstborn son to Microsoft (it’s deliberately campy) and couldn’t stop laughing until I gave her a juice box. Her friend, in turn, discovered the potential to create text-based adventure fanfic. (What have I done??) It was only too difficult for one person, a young girl about eight years old who put up a valiant but losing battle against it until I redirected her to the games that came with the operating system instead and she started playing Potato Guy. (It’s a virtual Mr. Potato Head. The kids seemed to like it a lot.)

One of our other volunteers, a second teacher with minimal (nonexistent?) Linux experience, seemed to not like me very much on the first day. Don’t ask me to name her, because I won’t. I think we got off on the wrong foot, and it was exacerbated by the reality of how disorganized the first run through the activity was, which had been partially preventable if my (and everyone else’s, honestly) brain hadn’t been scrambling around like a drunken monkey. It’s not like we had a dress rehearsal for this sort of thing. I think the kicker was that I’d dropped her online class earlier this semester, and it’s hard not to take that personally; I know that it was because of work overload from my other classes and how well I don’t do with online stuff, but she couldn’t know that.

Whatever the cause, she seemed to kind of radiate disapproval the whole day; I tried to meet her halfway in my speaking to her, trying to apologize for the disarray, but I guess she wasn’t in a good mood. I gave up and got on with what I was doing. The second group was much better handled, at least.

But on the second day, she came back with what seemed like new respect for me, even before I took things over. Maybe it was the presence of the other teacher (the competent Linux teacher), who already had respect for me; maybe she’d spent the previous evening trying to fact-check my FAQ and decided that I was competent after all; maybe she decided that the way I bounced back on the second group the previous day meant I could run things all right after all. Maybe she’d just taken that second cup of coffee and the barista complimented her outfit, so she was in a better mood. There’s no way of knowing, I guess. But she was a lot more helpful then.

I rarely see people change their mind the way she did, and to me, that engenders respect in return–not stubbornly holding on to an ill opinion of someone like a lot of people do. I don’t know her very well, but I was pleased to have her help. So few people have the willingness to change a poor opinion of someone. I’m not trying to be condescending or even implying that I’m any better than average about that. Just… major kudos.

Anyway, that’s enough about the STEM thing.

I’m still kind of designing and turning over the job site in my mind. (I talk about the idea and my design changes for it here.) I want to build it, but I’m not sure where to start. I have basic, slightly dated knowledge of HTML and CSS, and of course I know Python, and I’d like to build the site on those. I think I’d rather not use big frameworks or anything like that–no Django, no Rails, DEFINITELY NO .NET, although I’ve cloned Django and I might poke through the code for ideas if I need to. I want to keep my code fast and lean and I want to know what everything does.

My experience with web design has been pretty limited since I was 13-15. Even this blog is just a plain old WordPress site. Still, it’s not the front of the web site I’m worried about; it’s the backend. Databases? Files? Search? It’s the real code design stuff that I just don’t have the experience to be confident with, which school can’t teach, and the backend stuff, that school won’t teach because it’s too preoccupied with showing you how Microsoft’s latest product “solves that problem for you” and teaching that instead. Paradoxically, this is a very good argument for trying to get into it and screwing it up so badly that I learn.

I’ve got notes in my design notebook about the stuff I plan to do better, which is a lot easier than actually trying to do it better. But I need to get to the latter sooner or later.

I’m reading a new book. It’s called The Charisma Myth–it’s all about how charisma isn’t inborn and can be taught, and then turned on and off like a switch. It’s a really good book.

It says that charisma is composed of three main components: presence, or how in-the-moment you are and how focused you are on other people when you speak with them; power, or how much influence you have to potentially change people’s situations for better or worse; and warmth, which is how compassionate and empathetic you are towards people.

Basically, others assess 1) whether they have your attention, 2) whether you have the power to do stuff for them, and 3) whether you seem like you’d want to. If the answer is “yes” across the board, you have their immediate attention and they want to be around you.

Then the book goes on to say what actions you should take to increase those three qualities. Focus on the feelings in your toes to bring you back to the moment and increase your presence. Visualization and thought exercises to increase your apparent power and warmth. So much of charisma is in body language, and body language is so hard to fake, that you have to learn to manipulate your brain into feeling confident and powerful, and warm and full of goodwill, so that your body language follows. None of those are bad things and none of them change your personality–they just make you kind of a more attractive person to be around. They make others feel better about talking to you.

The book goes on to explain that there are four styles of charisma (actually, it hints at more, but these are what it touches on).

  1. Focus: people are drawn to you because you pay attention to them, because you seem genuinely interested in what they have to say and respect their ideas and opinions.
  2. Visionary: people are drawn to you because you have some big idea you’re intent on bringing about, perhaps something that promises to improve people’s lives. They feel inspired by what you say and more creative after talking to you.
  3. Kindness: people are drawn to you because you broadcast loving acceptance of them for who they are. They feel they can be themselves around you.
  4. Authority: people are drawn to you because you’re in charge. You seem like an impressive decision-maker with some sort of power, so they think you might be able to help them or do things for them.

Everyone has some kind of charisma to some degree, often a mix of them. You shouldn’t try to adopt a style that is alien and unnatural for you, and you need to be wary that you use the right style in the right situation. You should also try to cultivate as many as you can, so you’re adaptable.

I naturally have a fair bit of visionary charisma, particularly in my writing. (But you knew that, didn’t you, you clever thing?) But I think I’ve been walking around with a lot more authority than I’ve realized. I think that’s a big part of why people were so wary of me in high school and thought I was unapproachable. I wear nice clothes–I don’t generally leave the house in sweats or yoga pants unless I’m sick or in costume, and I’m lucky enough that my family can provide me with more expensive, good-quality clothes.

I used to be able to sneak into the school library to sit out a period I technically wasn’t supposed to have free under the usual rules, without leaving the paper trail of signing in, by walking past in my wool trenchcoat with a gait that suggested I was supposed to be there (I copied the quick, confident walk of the school administrators). The librarian rarely looked up, and when she did, she ignored me. Even though I had turquoise hair at the time. My body language just said that I was not to be stopped and bothered, so she didn’t. And when I sat around reading and knitting, nobody thought I was out of place.

This mostly went away when I got to college, where nobody knew I was underage until they got to know me a little better and had already seen that I wasn’t so unapproachable. And the average level of confidence is higher around here, so I didn’t stand out quite so much.

So, apparently I channel authority well? But… that’s not the most appealing of the charisma styles to me. I’d rather make people feel respected (focus) and then inspire them to go do great things (visionary). I don’t really want to boss people around. If other people rely on you to give orders, they can’t handle not having you around, and they can’t go off and do great things on their own. Besides, it’s more fun to be doing great things too rather than making other people do them. I prefer the power that comes from controlling things (like computers), rather than that of controlling people, and I’d rather persuade than barge with my ideas. I’d be okay with directing and organizing a bunch of people to do something they want to do, though. There’s a lot of overhead and grunt work in organizing a collaborative effort. But it probably wouldn’t be as fun as doing things myself.

Uh… looking back on that paragraph… I wonder if I’ve just read Ender’s Game one too many times or if there was a seriously deep reason I connected with it the first time I read it. Anyway.

Focus isn’t something I currently do well, because my mind wanders so much. Even if it’s wandering on something the other person just said, it doesn’t make them feel so great if it looks like I’m zoning out. I’ve decided I’m going to work on cultivating that.

As for kindness charisma–I actually do care about people and try to think the best of others. I also happen to be completely awful at expressing it. (It’s an INTP thing.) I’m actually a pretty warm person, but the associated body language isn’t really wired well into my brain. (Authority’s wired in instead. I’m so girly.) I tend to surprise people by doing nice things for them instead, which catches them completely off guard.

Here’s another story. I was taking a college Psych course in my senior year of HS, and I was working on knitting a super-long pink scarf as a Christmas present for one of my friends. After having worked on it during class for a couple days, a girl comes up to me and asks, “Hey, will you knit me a scarf?” In retrospect I think she meant it jokingly, but I was so caught off guard that someone had talked to me that I blinked and said, “Uh… sure. What’s your favorite color?” It took a minute for her to recover and reply. The next day, she asks, again jokingly, “Hey, have you finished my scarf yet?” I say no, I want her opinion on the color first, explaining that I don’t have any light purple yarn and offer a skein of baby blue instead. She’s taken aback but accepts it and I start knitting. I give it to her a few days later (I was really fast at that point through practice). By then of course she was totally cool with it and thanked me.

Knitting seemed to make me look more approachable, I think. A lot of people were more willing to talk to me while I was doing something so low-key. Especially working on something as absurdly pink as that scarf was. (It was a copy of the really long, bright pink scarf from Homestuck. It was like eight feet long or something crazy and took me… I think well over a month?)

I know that book isn’t technology related, except in the sense that people skills are important in this field, as in any. But psychology is also one of my interests, as are self-analysis and social analysis, so I hope my readers don’t mind my going off on tangents like this.

For sticking with this really long post, here’s a set of Muse songs. These three were among my very favorites for their incorporation of beautiful classical music. Part 3 is particularly striking.

It seems there’s also a Part 4 on YouTube that I’ve never heard before? I’ll investigate it when it isn’t 3 AM.




I made a thing!

I wrote this text-based adventure script to introduce some basic Linux commands. It’s mainly for the Linux thingy I’m doing on Friday with the Plant Yourself In STEM event, but it’s probably useful to more people than that.

I only got the idea earlier today (err… yesterday now), so I haven’t spent a TON of time on it. I spent more time writing the story than putting it into the code, which is brain-dead simple (validation of specific, static commands). There are certainly more commands I could include and better ways to write it out there, but right now it’s functional and goofy and not boring or over-technical. I’m quite pleased with it.

It lives here and it’s MIT licensed, so you can play it for yourself and/or improve it as you please.

There’s a cool new open source project in town

It lives here and it looks neat 😀

It’s called braindump (also capitalized BrainDump), and for now, it’s a note app on that web site. However, the creator, Levlaz, says it’s just a proof of concept; he wants to make a “notes platform” out of it. I’m not entirely sure what that means, but he’s planning to elaborate about it later, over at his dev blog.

For your code curiosity convenience, braindump’s website and GitHub repo are linked over at my Links page, so you don’t have to hunt down this post if you lose a bookmark or whatever.

It is certainly not perfect. To me, this is part of what makes it fun, though–that it’s alpha-release, small enough to tinker with, easy to see what it’s supposed to do, and that it still has bugs to hunt down.

Have fun, readers! 😉

Open Source: What It Is and Why It Works

Rebekah Yoder

Open source has dramatically changed the landscape of how software is created and how software is treated. There are thousands of open-source programs available for use, learning, and as a basis for other programs, many of them free of cost. Yet most people don’t know what open-source is, let alone about the massive library of code available to make their lives easier and their businesses run more effectively.

What Is Open Source?

An open-source program is a program for which the source code–actual human-readable instructions to the computer, written in a programming language–is available for anyone to see, modify, and redistribute. There are some more formal requirements beyond that for a program to be considered open source, but they’re fairly general and easy to follow: things like lack of discrimination against users and no restrictions against the ways you can distribute or use the program. Pretty simple stuff.

There are different open-source licenses with different permissions. The popular open-source hosting platform GitHub has carefully put together a simple explanation of the different licenses.

Why Does It Help Me?

Using open-source software has many benefits. For the average home user, it often means an inexpensive or free piece of software as a replacement (quite often an improved replacement) for some more expensive proprietary program. Common replacements might be using a Linux distribution such as Mint or Ubuntu instead of Microsoft Windows, or using GIMP (the GNU Image Manipulation Program) instead of Photoshop.

Beyond the benefits of price, the user support for open-source programs tends to be superior over proprietary options. Popular open-source programs may have a very large and dedicated developer base. The Linux kernel lists over 5,500 contributors as of this writing, and even smaller programs such as GIMP (185) and gedit (251) may list several hundred developers adding features and fixing bugs. Keep in mind that gedit is simply a text editor, but if you find a bug in it or have thought of a feature a lot of people would find handy, there are 251 developers ready to hear what you have to say.

Furthermore, if you happen to be a developer yourself and you find a bug, you can change the code yourself to fix it, and then share your changes with everyone else by issuing a pull request on GitHub, which lets the person maintaining the code incorporate your fix. This is in opposition to waiting for your proprietary source to fix things themselves, at the expense of your time. (And, if you’re Dilbert’s company, money. Lots and lots of money.)

Dilbert comic strip by Scott Adams

[Dilbert comic strip by Scott Adams, used under Fair Use for commentary in this essay]

The developers are just a slice of the help you can receive if you have trouble with a program, however. Large projects, such as the different Linux distributions or Mozilla Firefox, often have a dedicated forum or two full of the program’s users, who often cheerfully answer questions posed by any newbie to the software on installations, how to use certain features, and how to solve problems. Tech support lines provided by corporations, on the other hand, are notorious for their automated phone systems and ultimately not very helpful “assistance.”

Freedom In Software and the term “Open Source”

Open source started with the Free Software Foundation, which has a philosophy on the essential freedoms of software users: to run the program, to study and change its code, and to redistribute the original and/or the user’s own modified version. The Free Software Foundation is responsible for the GPL (GNU Public License), among several other popular open-source licenses, as well as a large chunk of the software used on Linux.

Open-software grew from the FSF’s free software, for two reasons. One was that not all developers agreed with the philosophical views of the FSF, even if they wanted to encourage collaboration; the other was that some people were getting confused as to what “free software” meant. Eric S. Raymond, a prominent developer in the open-source community, explains it very well in an introductory document to open-source developer culture:

What is now called “open source” goes back as far as the hacker community does, but until 1985 it was an unnamed folk practice rather than a conscious movement with theories and manifestos attached to it. This prehistory ended when, in 1985, arch-hacker Richard Stallman (“RMS”) tried to give it a name — “free software”. But his act of naming was also an act of claiming; he attached ideological baggage to the “free software” label which much of the existing hacker community never accepted. As a result, the “free software” label was loudly rejected by a substantial minority of the hacker community (especially among those associated with BSD Unix), and used with serious but silent reservations by a majority of the remainder (including myself).

Thus, the term “open source” was coined, allowing a distinction from the ideology of the FSF. (Quote is a continuation from the last source.)

The term “open source”, however, had not yet emerged; it would not do so until early 1998. When it did, most of the hacker community adopted it within the following six months; the exceptions were a minority ideologically attached to the term “free software”. Since 1998, and especially after about 2003, the identification of ‘hacking’ with ‘open-source (and free software) development’ has become extremely close. Today there is little point in attempting to distinguish between these categories, and it seems unlikely that will change in the future.

The FSF and GNU Project, however, still distinguish between the two terms.

Are They Really Better? Why?

Open-source advocates are often heard making a case for the superior quality of open-source programs.

Bugs are fixed quickly

“Given enough eyeballs, all bugs are shallow.” -ESR

The idea is that with enough programmers looking at the same buggy code and trying to fix it, the best fix can be found. This is usually the simplest fix, which is implemented the fastest and pulled into the main code branch the fastest. If the simplest fix is not the best, a later programmer can always offer a second pull request and explain why he thinks his solution is better. Depending on the judgment of the project’s main developer, this may be incorporated or not.

Multiple options

The judgment of whoever is in charge of the code base is typically respected and let be–however, there are some cases where the differences of opinion are large enough that the dissenting programmer may copy in the rest of the code base and start his own version of the project. To the proprietary world, this often receives a knee-jerk reaction similar to that when someone mentions an act of plagiarism, but it’s completely normal in the open-source world. It also allows users to choose which version of a program they prefer. In theory this might mean that a single program could have dozens of versions, but due to the effort involved in maintaining an open-source project, forking projects into entirely separate entities tends not to happen unless there are serious design differences that might be important to users.

Indeed, there is a single open-source program with dozens of different versions: Linux itself. (No, I’m not talking about the actual kernel; I won’t get into semantics here.) There’s a reason there are so many distributions; each is a little different, because there are many types of users and they want different things from their computers. Ubuntu and Mint are tailored for desktop users, Red Hat for enterprise use, Kali for security testing, and Debian for servers. Of course, they aren’t limited to those roles–I personally am very fond of Debian for programming and desktop use–but they do have different interfaces, different programs installed by default, and in some cases slightly different software available. Linux is a very good example of a forked project which morphed and evolved into something where users would care about choosing a version.

Finally, a developer has the last and ultimate option of changing the program herself.

Users are listened to more

With less time spent on bugs, programmers are freed up to work on feature requests.

“The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.” -ESR

Users who are also co-developers have an advantage over corporate developers who may or may not have actually used the product they’re working on from a user’s perspective. The latter will have opened the program for testing, but have they tried to use it for its intended purpose? Maybe, but depending on the product, probably not. The developer-users of the open-source world therefore have an advantage in how well they can relate to comments and feature requests, even from users who are not fellow programmers.

Developers are self-selected for interest in the project

“To solve an interesting problem, start by finding a problem that is interesting to you.” -ESR

Really, this is a huge advantage over corporate programmers who have merely been assigned to tasks without mind to whether they enjoy a particular project. The average software company’s level of priority given to “Are the employees having fun?” might be a pool table in the break room. They usually don’t consider that the personal preferences of a dev do have an effect, for better or for worse, on the quality of their work.

Programming is a highly creative pursuit, so the mindset and emotional state of the programmer matters a lot. Developers don’t like to be bored. They work best on things they’re interested in. It’s a natural human reaction, not just laziness; they can’t help it. Imagine how productive you’d be sorting rocks–unless you’re a geologist, in which case you might like sorting rocks and be very quick and accurate doing it.

The video below (around 5:30) makes an example of one Australian software company named Atlassian. They gave their programmers one day per quarter–24 hours–to work on whatever they wanted with whoever they wanted, without interference, and they got to show it to the rest of the company at the end of the day. The result, as stated in the video, was that the programmers quashed a plethora of bugs and made a lot of great new stuff too.

In the open-source world, no one is forcing you to make something you don’t want to make.* For instance, if you don’t like making database software (and a lot of programmers don’t), then the only time you’ll be working on it in the open-source world is if it’s a crucial part of something you do like working on, which makes the drudgery easier to take. Or you may be able to foist off work you don’t like onto co-developers who like it better (and will therefore do a better job with it).

This self-selection means that programmers who will be most effective at a job are the ones who gravitate towards completing it, improving the overall quality of the software.

*Excluding those instances in which you’re getting paid by your company to work on a specific open-source project. That happens! But people who are skilled enough to get those jobs can probably take their pick of positions anyway; there’s no shortage of options for them.

Effects on the economy

Naturally, when open source first took hold of the software community, many feared that software development job openings would take a hit. Not so–we’re finding that it’s creating them. More and more companies are using open-source software and need developers and system administrators to support their projects.

Now, it’s common for software job applications to ask for a GitHub account. There’s been some controversy over whether it’s ethical to require workers to produce work without paying them and allow anyone to see it (if you want private repositories on GitHub, you have to pay to upgrade your account). However, judging candidates on the merits of their personal coding projects is arguably more effective and less discriminatory than requiring certifications or a college degree, as the latter requires money which would rule out candidates living below the poverty level and prevent them from finding low-risk, high-paying jobs in technology; the former merely requires a computer with an Internet connection and free time. (Admittedly, this is a large privilege in itself, but the barrier to entry is much lower than when formal education is required.)

In the late nineties, however, big software companies weren’t sure if they were going to survive the open-source revolution. Microsoft in particular panicked, especially when the infamous Halloween Documents were leaked, revealing how nervous they truly were. (There was some doubt over whether the documents were genuine, but Microsoft has indeed confirmed their authenticity. Admittedly, that citation is old, because this all happened 15-17 years ago.) The documents speak of tactics such as “FUD” (fear, uncertainty, and doubt) which were used to make users unsure about trying Linux and open source software, an unknown quantity, and to stick with Microsoft products because they had a known brand name. There’s also a suggestion of trying to turn open protocols into something controlled by Microsoft as an additional tactic against the open-source community. Whatever you think of Microsoft and the relative validity of the papers, this is a good example of how anxious software corporations were becoming in the face of open source.

But the question of whether open source is good for the economy isn’t really in debate, at least not any longer, and not by anyone who understands the concept of wealth. Any action or process which creates something valuable–like software–is good for the economy in general no matter who gets money for it and how, or even whether they do. Something exists that did not exist before (a good or service), somebody needs it, and money is only a stand-in to represent that creation.


This essay is now over 2,000 words, so let’s recap.

We’ve learned that open source is a software development method in which anyone can see, change, and redistribute the code. It’s better for users and companies than proprietary software because it’s often free of charge, it can be modified by the user, and it’s often well-supported. It’s better quality in general because there are lots of people fixing bugs, lots of different use cases being supported because anyone can make a different version of the program, feedback is taken more efficiently, and the developers enjoy what they’re doing. It’s also great for the economy, because it’s been creating jobs (despite fear that it would destroy them), and it’s also been creating wealth, which makes our society a little bit richer every time something valuable is produced.

I’ve been trying to come up with a joke or at least a conclusive-sounding sentence to end this essay, which is fast approaching 2,500 words, like a phone call that won’t end because neither party will admit they want to hang up. So, you’ll have to make do with that half-joke, and my thanks for reading.

Happy coding!

Sites linked in this essay

These are general addresses of sources I used earlier, listed here to outline where I’m getting this information. In some cases a site was used more than once. To find the exact pages I draw from, use the links in the essay.


The Open Source Initiative:

Github and related sites:,

The Free Software Foundation and related sites:,

Product websites

Linux Mint’s official website:

Ubuntu’s official website:

GIMP’s official website:

Mozilla Firefox’s forum:

Papers, essays, videos, and magazines

[I list ESR’s papers separately, as they’re important citations and his web site can be harder to navigate if you haven’t been wandering it for a while.]

Eric S. Raymond’s paper on how to become a hacker (proficient open-source developer):

Eric S. Raymond’s paper “Cathedral and the Bazaar”:

Eric S. Raymond’s annotated versions of the Halloween Documents:

Paul Graham’s essays:


Computer World:

Info World:

Microsoft’s admission:

Last but not least:

Dilbert comic:

The Problem Of Software Licensing

This wasn’t a request, just a personal debate of mine.

Meet the main contenders. On the one hand, we have the likes of DRM: making it difficult not only to pirate their software, but to use it legally after you’ve legitimately bought it.

On the other hand, we have Richard Stallman and the Four Essential Freedoms:

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Paul Graham also has an essay that’s pretty sympathetic to Stallman, although it doesn’t explicitly agree with him on the points mentioned above. It simply takes a stand against DRM and restrictive copyright licensing.

I don’t fully agree with either of these. I agree with PG, and my views are closer to Stallman’s side, but I also think the freedoms Stallman considers essential would prevent people from being able to profit from writing software. As someone who plans to profit from writing software as a living, this puts me in a bit of a dilemma.

The main problem, as I see it, is that software “piracy”–the act of seeing a developer (or any digital creator, such as a music artist) selling their work for an amount of money, and choosing to deny them reimbursement for their work and for making your life easier by downloading it elsewhere even if you could have paid for it fairly–is not taboo.

I can sympathize with so-called piracy (which, I agree with Stallman, is a pretty strong word for something that isn’t always bad) in the case where one actually doesn’t have the money. I don’t care if high school students want to grab something I made from a torrent site or whatever instead of… not paying for it and not benefiting from it, which is their other option. I want to help people with my software. I also sympathize when the software is patently overpriced. (Photoshop, I’m looking at you. You’re worth, like, fifty bucks… not two hundred.)

So, what constitutes “bad” piracy? Is “good” piracy even piracy? It’s clear the issue isn’t black-and-white. To me, the license applied to software needs to consider critically precisely which behaviors are to be prohibited, and which ones allowed.

I ran a quick Google search and found a post on entitled “Is internet piracy a bad thing?” There’s some intelligent discussion going on about the benefits and costs of piracy in general.

Here’s one against piracy:

Internet piracy is theft.

Internet piracy is not as bad as stealing something physical, such as a CD or DVD, as no one lost money from the physical creation of the item, but, it is still theft, and still bad. While it may not be physical, the parallels are unquestionable. In both situations you are getting something for free that has cost others lots of time, money and effort to build. Films especially cost huge amounts to make, often hundreds of millions of dollars, in exactly the same way to how it costs someone to create a handbag or a car. If internet piracy was not an option, you would either not watch said film, or buy it, giving the creators money and consequently payment for their efforts. However, as internet piracy is an option, there is no motivation for people to pay. If everyone pirated this would mean that all films would result in major losses, and film/computer programme/music would all become charitable things relying on donations to be made. Instead, the current situation is some people pirate, and others pay the proper price, giving the creators the money they deserve. But that itself is unfair, as why should some have to pay while others do not? No matter how people twist it to justify what they are doing, despite the fact internet piracy is not stealing something physical, it is still theft, you are not stealing from a shop owner or item-owning citizen, but you are stealing from the creators of whatever you pirate.

Here’s one that says piracy is sometimes okay:

It isn’t [a bad thing], within limits.

Lets say a movie isn’t available in your country. Maybe it will be- in a few months or so (in a cut and extra-less version), but your friends from overseas are already touting how good it is. Perhaps there’s a game that’s two times more costly in your region than anywhere else in the world. It could be that you’ve been screwed over by DRM and locked out of your *legally purchased* software (very, very frustrating, and it really bothers me when a pirated product is *better* and *easier to use* than the legal one, because it doesn’t have the damned DRM) It might be you have your wallet ready, but the software is prohibitively expensive. Say you’d love to pay to watch those episodes of Game of Thrones, but you really don’t want a full HBO subscription. There are instances in which piracy is justified- it can be a means of protecting consumers from bad industry practices, like overpricing, awful DRM (screws over only paying consumers!) or idiotic distribution practices.
Of course, piracy is terrible if it means profiting from someone’s work, plagiarism, or not paying for something you could have reasonably easily obtained legally.

I agree with both, as you might have gathered. I didn’t write either, however.

I’d like to call attention to the last line of that second one:

“Of course, piracy is terrible if it means profiting from someone’s work, plagiarism, or not paying for something you could have reasonably easily obtained legally.”

This lists three things (really, two behaviors) that are to be prohibited:

1. Plagiarism, which we can probably all agree is awful;

2. Benefiting from someone else’s work without giving them the payment they’ve asked for, if you could have reasonably obtained it legally.

This is my view in a nutshell. I think it’s a lot of people’s views in a nutshell. Now, the question is how to keep those behaviors from happening, because I think the current measures are far too restrictive. There must be a better way to do this.

To prevent both of those things, most software companies only distribute binary files. They don’t distribute source code, because a) their competitors could see how their software worked and copy it, and b) it would be easy to illicitly redistribute their programs by just releasing the source code to the Internet. Many software providers also prevent redistribution of their binaries by trying to locate and eradicate sites which distribute them illegally.

Windows, notably, does not do the latter. Not because Microsoft is somehow more noble… they’ve just found a way around the latter concern. Windows copies only work if you have a product key. I think this is a hint as to how we could get things to work.

Another hint is Mac OS X. Part of the code is open, and the other part is closed-source. I consider this fairly acceptable, although it definitely isn’t a perfect solution.

A third hint is actually Chrome OS. Most of that OS’s software is cloud-based. You need server support to run it.

These three hints, working together, can fight at least the second behavior.

If your software is cloud-based, you can open up most of your code. This is because if your software is cloud-based, you can make your users pay for an account to log in to the server, or a product key.

The first option (access through accounts) is basically how Google Play works! (At least on mobile phones.) And as we’ve found, that works pretty well. 🙂 I, at least, haven’t heard much about pirating apps. I’m sure it happens, but not much. I wouldn’t expect it to pick up just because the source became available, either, unless the price of the software exceeded the price of publishing an app to Google Play (about $20, I think) and supporting it. And if it’s cheaper to reproduce and maintain on your own (something crackers are highly unlikely to do, let alone do well), that probably means the original was far overpriced.

The second option (which you have to take if you aren’t providing server support–i.e., if it’s a piece of desktop software) requires making part of your code closed-source. Namely, the part that requires your users to need a product key. The problem here is that if you distribute that binary in the middle of untainted source, piracy-minded folks will just strip it out of your package and use the rest of your source code. So maybe you have to hide your main method or close off one feature that it’s inconvenient not to have, thus making it inconvenient to pirate your software.

(A nasty/fun hack one could try as an alternative to this would be to program the product-key-requirement code in Whitespace or something. Crackers, on the whole, wouldn’t be smart enough to catch on.)

[Edit: A note on product keys. I object to product keys and licensing that say you can only run the program on one machine. I think the legal qualifier should be that you’re licensing the program to one person, not one computer, and deal with licensing for institutions like schools and businesses separately (this, I think, is how the current model came about). Licensing to a person is pretty painless on both sides. Having a user sign into an account which includes their billing data in order to access their program seems pretty effective; at most you get them sharing with close friends and family, which helps (marketing) more than it hurts.]

I think a lot of big corporations would object to this idea, though. They’d be worried about their competitors accessing their code and copying it. Indeed, I’d start off being nervous about putting tinypapers out there like that, at least right now.

The trick is that you have to have a brand and a following first. You have to be recognizable. Furthermore, your users have to like and be loyal to you. If someone else stole Photoshop’s code, even if they had no patents, people would probably recognize that it was stolen Photoshop code. However, a lot of hackers would go, “Hey, awesome, we don’t have to support Adobe.” Adobe has had a history of producing crummy, overpriced software–Flash and Dreamweaver certainly come to mind. Photoshop isn’t crummy, but it is overpriced.

Whereas if I were to establish a brand with tinypapers–make it well-known and recognizable–I’d be more likely to have a good relationship with my users. I can afford to listen to what they’re saying they want. I can afford to give them spectacular customer service. I can afford to start fixing a bug the hour they report it–perhaps even while they’re on the phone with me. I also don’t have a history of ripping them off, and don’t plan to sell my app for more than a dollar or two–more probably, though, I’d distribute a free version first with one line of simple text ads per page–and charge more for server space if/when that becomes a thing.

At that point in my business, assuming (hoping!) I get there, anyone trying to copy me would most likely be ignored, because my users by then would like me too much. The competitor also have to learn to use the tools I’m using, which not many people know how to do, so I have a head start. Because I’m young and not tied to a programming language, I don’t hesitate to learn a new framework like Kivy, even though it’s a steep learning curve.

There would be a trade-off to opening up my code: many companies would not want to buy tinypapers. But I think those would probably be miserable companies to work for, so maybe that’s a good thing. It also might make it harder to get investors. But if those investors care more that my code is open than whether users like my product, they’re probably dumb investors.

It’s tempting to open up my code on GitHub now. I really like the open-source development methodology, the community surrounding GitHub, and the version control software itself. It’s tempting to think that my repo wouldn’t be seen by much of an audience at first anyway. But I think, for prudence’s sake, I’ll hold off for now. It’s kind of a dumb idea to let potential competitors know that much about a larval startup.

I’d really like to hear your opinions on this, readers. Honestly, I’d especially like Paul Graham’s opinion, because he’s seen so much of the landscape I’m talking about and has good powers of analysis (and I’d like to see a more recent essay of his about it). I’ll try emailing him, but he’s probably really busy. Nevertheless, my habit of bugging people I admire hasn’t done me any disfavors yet. 😉

ESR, if you happen to be reading this, I’d really appreciate your comments too. You’ve probably heard a lot of discussion on this topic, and generated quite a bit of it yourself.

Edit: Other Thoughts

It was observed by ESR in “Cathedral and the Bazaar” that repositories which encourage others’ contributions to their code have fewer forked projects running from them; changes got incorporated into the main branch rather than spinning off into their own projects.

It occurs to me, then, that if a startup were to open up their code, there is a way to prevent certain competitors–the ones who are at least partially driven by wanting to make better software. A hacker may look at a commercial application, think, “I can do better than this,” and write his own, thus becoming a competitor. But if the application’s source is open, and the people running the business behind it aren’t territorial about their code, he can apply as a sort of temporary consultant for whatever feature he wanted to program in. Basically, he could program in the feature, and offer it to the company with an estimate of what he thinks it’s worth (maybe $50-$2000 if it’s somewhere from a little bug fix to a neat but not huge addition, or he could ask for stock if it’s particularly large). Then the company could accept or reject it, or negotiate price if necessary. Since they (hopefully) know their users better than J. Random Hacker does, their decision would probably be respected.

This would also solve the hiring problem many startups face! Anyone who provided a few good fixes or features like this would be a very promising candidate. And of course it would make the company’s software better, which is always excellent.

Big companies buy startups for their software (the basis of their market) and their people. Why can’t startups buy code chunks and job candidates?

A few more projects

I’ve started teaching Python to my 12yo. brother Ben. He picks it up really quickly and asks the right questions; his problem is that he doesn’t make the mistakes that the Python book keeps trying to get him to make, the ones he’s supposed to learn from. He’s already meticulous, so if I don’t intervene and point out all the ways you can screw up a program, he won’t have the experience of knowing what it looks like when you do make stupid mistakes. Because everyone makes stupid mistakes in programming. It’s just a thing that’s going to happen, no matter what.

So far, the design patterns book I’ve been reading has covered the Strategy pattern, the Observer pattern, and the Decorator pattern. I like Strategy and Observer, but I don’t like Decorator. I keep getting this feeling like… I would do it differently, use more of a Strategy-shaped design. The book keeps talking about a “Factory” pattern; maybe that’s what I’m thinking of but can’t pin down. I just don’t like Decorator on its own. It seems kind of unnecessarily complex… obtuse… clunky. Maybe I’ll like it when combined with Factory, or maybe I don’t understand it well enough to get why you’d want to do things that way.

Meanwhile, the book is teaching me more about OO principles than any programming book I’ve ever seen. Between Head First Design Patterns and Google, I’m seeing a lot more of what you can do with objects via example than is ever really explained in other contexts. School teaches you to type

public static void main (String[] args) {  }

(or equivalent for non-Java languages) but never actually shows you a program where you use publicly-accessible methods from another class; I’m still not really sure what static does. They teach you what classes and objects are–sort of–but don’t teach you how they can really be used. They don’t teach you what an interface is, or how libraries actually work. They teach you syntax and how to solve toy problems. I have a feeling I’m going to end up teaching some other new programming grad I’ll have to work with about everything the classes missed. In fact, if I can find the patience to type these things up, maybe I should post them here.

I can see my own progress by the fact that the source code for Tetravex, which I downloaded on my Debian VM, is now magically understandable. Not sure how that happened, but there are a few bugs I want to send in a patch for–if they haven’t already been fixed. If I do that, it’ll be my first contribution to open-source. 🙂

Thoughts on two papers I’ve been reading


I’ve been continuing to study. The Linux class is going all right; I’m halfway through and just took my midterm exam this past Thursday (which was basically, “do you know how to use basic command line commands? yes? kthxbye, this class is only 30 minutes long”). Most of what we’ve gone over so far was stuff I already knew how to do… but I think we’re past that now. It surprised me how much I’d already picked up from messing around with an OS I wasn’t even using as my primary.

The teacher thought I’d been using Linux quite a bit longer than I had. Actually, whenever I clarify that I’ve only played with the system, she kind of deflates a little. At least, that’s how my brain parses it. This teacher’s really hard to read. I wouldn’t want to play poker against her. She knows her stuff and she’s pretty friendly–definitely NOT a bureaucrat–but she seems jaded, and often worn out from her day job as the school’s only Linux tech by the time we see her. Oh, and she has a real thing for popcorn. Not related, but I thought it was funny.

I’ve been studying on my own, too. I’m on my second read-through of ESR’s Cathedral and the Bazaar. I agree with the points in his paper (unless I’ve missed something). The paper is a pretty thorough study of how open-source works and its advantages over closed-source, corporate development. It also goes in depth as to ESR’s proud parenthood of his beloved baby program, Fetchmail. 😛 He provided his experience with Fetchmail as an example, but if a guy could be more affectionate and nostalgic towards a set of instructions to be given to a hunk of organized sand which displays lights in patterns in a box, I don’t know how.

I enjoyed CatB. I found myself finishing ESR’s sentences once or twice before turning the page on my Kindle. I made a few observations that I think he missed, too, and once I’m done with this second read-through (in which I’m taking notes on his main points and what I think can be extrapolated and applied to modern programming–a lot has changed in the, what, 15 years since he updated the version of the paper I have), I’ll try to remember to post them here. I also think that if closed-source companies are going to keep writing and selling software, they should at least take a page out of the open book and use open-source tactics to help develop their software. It would mean that closed companies might produce better software, and that’d give the help-desk people a bit of a break–plus the benefit of getting closed companies used to the way open-source culture works and maybe making it easier for them to leave closed-source behind in the future.

Perhaps I’ll end up writing my own paper suggesting how they should do this. I don’t think I know enough about software companies’ internal structure to do so now, however. But I will later, because I intend them to hire me one day. (Not Microsoft, though.)

I’ve also been reading–trying to read, anyway–the Halloween Documents. (link)

These are much less pleasant to peruse, but I want to know what they’re about. It’s really hard to follow the logic. I’ve gotten 2/3 the way through the first paper and I’m starting to think maybe that’s because there isn’t much logic to be found. Is this how they write code, too?! CatB mentions a quote from somewhere that basically says that every time a group develops a system (like a piece of software), its structure mirrors that of the way the group communicates within itself. So if this is how a Microserf writes a paper–with disjointed logic and poor organization–is that what Microsoft’s code looks like?

Speaking of that quote, I remember one of my observations that got missed by ESR–probably because I’ve steeped myself in a different era in programming. Actually, it’s my favorite of the things I noticed. Consider:

Any structure a group writes will mimic the way the group communicates.

Brooks’s Law that adding more developers to a late project makes it later is based on the assumption that every member of the group needs to communicate with each other, and the overhead cost of that communication causes the lateness.

Open-source development models eliminate Brooks’s Law because they’re better organized; different developers need only really communicate with the lead dev, not all of each other.

Now consider procedural programming versus object-oriented programming. In particular, look at object-oriented programming and compare it with open-source structure.

In each program, there’s a main method that runs first. It calls the other methods, which do various tasks within the program depending on user input, but often the main method itself doesn’t do much. There are probably some variables in main that get passed to other methods, but main doesn’t do much heavy lifting, on the whole. Those tasks are delegated to other methods. main just organizes them and fits them together.

In open-source, the lead dev (or lead devs, up to about 3 according to ESR) have an idea, write up a basic “scaffolding” or infrastructure for their program, and then make a call out to the open-source community to come and help with their idea. Then, if the idea catches on, an extraordinary amount of delegation takes place. Other hackers do smaller pieces of the process to help, and the leads’ job is now more that of a manager than a coder–although they’re certainly not to be mistaken for the useless lumps that pass for managers in many corporations, or for the managers who don’t actually have very much to do with the code and just try to keep the bureaucrat higher-ups out of their coders’ hair. They are in fact what managers should be: competent people overseeing a project.

Anyway, where was I? Oh, yeah. The Halloween Documents.

I don’t need to bash how terrible the tactics described are, or how obtuse the writer is. It’s pretty obvious to anyone who reads the thing, especially with ESR and TN’s comments interspersed as in the link I posted earlier.

I will mention that the writing style is… obfuscated. ESR writes clearly, and explains jargon and techspeak terms alike where necessary to grok his points. But this Microsoft guy is writing out of some Micro-bureaucrat dictionary, and disjointed as his points already are, it doesn’t help in making the paper easier to understand. ESR’s paper calls back to previous points in many places, which underlines the paper’s internal consistency. Like calling a method multiple times in the same program, because you wrote it well enough to reuse it. But this other paper, this Halloween paper… it’s internally inconsistent in many different places and it’s hard to understand what the writer’s trying to say.

It also seems like it’s padded out by repeating points. Not just calling back to previous points like ESR does, but it’s as if the writer copy-pasted the first time he wrote out his points and then changed the wording and formatting, made it a bulleted list or something.

Trying to parse the thing is kind of giving me a minor headache, not to mention it’s boring to read. I’d like to get the other perspective, but it seems pretty mindless and it’s tiring to read. I’m going to leave it there for the night. Maybe there’s another alternate perspective.

I would like to know how open-source software would make a company enough money to make it a viable business path. Obviously they can provide tech support, but so can open-source forums. The thing is, open-source is fine on its own. It doesn’t need a company behind it. But companies generally like to be paid, and to be paid you have to be filling a need (or, like Microsoft, at least you have to make people think you’re filling a need).

I would like to make coding my career. But I also think that the open-source development model is so much drastically better than what could be done within a closed-source corporation, and I don’t want to produce crappy software because that would be a pain to write and a nuisance to maintain and support. I’d like to know how much of open-source culture could be adopted by a company without their losing so many rights they can’t make money. In other words, I’d like to find a way for a company to make money off of open-source, or if not, I’d like to make closed-source policies less terrible and the development structure more effective.

I have time to think about this, at least. I’m 17 years old, after all.