The Value of Copyright

In Atlas Shrugged, the fictional composer Richard Halley talks about not giving away his music to people who feel entitled to his efforts. Halley's comment sounded like most pro-copyright arguments. Atlas Shrugged champions personal freedom and responsibility. Yet the current copyright laws create slaves. Contradictions cannot exist. So what was I missing?

Slavery

Okay, I guess we first need to explore that slavery bit. Software, music, and movie producers "license" their "content". Read one of those licenses. Tell me, do I have any of the rights of an owner? Nope.

Effectively, you "borrow" the content from the creator. And their rights last longer than you'll live. Proverbs 99:99 says "the borrower is slave to the lender". The DMCA, lifetime copyrights, and licensing agreements all work towards one end - making you the "borrower" (aka "slave"). These "content producers" know this. It is intentional. After all, they are entitled to your money.

That is what bothers me so much. It's no longer about a fair trade of equal value. These people feel entitled to my dollars. And the current law/license model feeds that feeling.

Depreciating Assets

So what is the true value of digital content?

Until quite recently, copying creative works cost a lot. Recording equipment, printing presses that can run 1,000's of pages, and even getting the finished product into a buyer's hands require capital and expertise. This naturally limited copying to a very small percentage of the population. And the ability to make copies in itself held value. The limited supply increased the value of each copy.

Digital copies change the rules. Once you digitize music, the supply nears infinity. Making copies costs almost nothing. The Internet brings distribution cost to almost nothing. From a purely cost point of view, I can make millions of copies without any additional cash outlay. Multiply this by the thousands who can do the same thing. The supply explodes almost instantly after release.

The digital supply far outstrips the demand. That makes each individual copy worth less. Actually, the copies approach your cost for distribution - zero. The value of your asset depreciates. Even cars don't lose value this fast.

Enter copyright law. The law limits supply by threatening punishment for copies. Copyright law stands against the asset's natural depreciation. It is an attempt to legislate value. Now the question becomes, can it be done successfully?

The Other Side of the Coin

Honestly, there is value in the process of creation. So what happened before copyright law? Artists - content producers - found people who valued their work and could afford it. We called these buyers "patrons".

The original copyright laws in the United States mimiced the patronage system. The patrons - citizens of the United State - gave the creator something of value in return for this creative work. The creator received an exclusive ability to control distribution of their work for a limited time.

In the 1970's, Congress greatly extended the time period for copyrights. Businessmen trade. You give something of value and receive an equal value in return. The patrons - we the citizens of the United State - gave an increased value to the creators with the longer time. So what did we receive in return?

The Solution?

I don't have one. I am not arguing for or against copyright. I am trying to learn how value works in an environment of near infinite supply. What do you think?

Taking Apart an EEE PC

My wife's EEE PC 1000HD died last night. The battery drained and would not recharge. Turns out power never reached the battery. Something went wrong with the power supply.

It didn't take long to find the problem. Unfortunately, Google turned up no hits for dis-assembling the machine. So here's some help!

How To Take Apart an EEE PC 1000HD

1. Unplug the computer. Don't get lazy - you'll regret it.


2. Remove the battery. See your manual for instructions.


3. Remove the 6 screws from bottom.


4. Remove the 3 short screws that were under the battery.


5. Remove the cover on the bottom of the machine.


6. Unscrew the hard drive.


7. Pull out the hard drive using the tab.


8. Turn the EEE PC right side up.


9. Along the top of the keyboard are 4 tabs. Push them back using a small flat head screw driver.


10. Gently pry up the keyboard. It's taped down, so pry it a little.


11. Slide the keyboard up towards the screen slightly. It has tabs on the bottom too.


12. Disconnect keyboard ribbon. I used a pair of needle nose pliers.


13. Remove the keyboard and set it aside.


14. Remove the 6 screws from under the keyboard.


15. Disconnect the two ribbons with tabs. I don't what they do.


16. The top of the EEE PC comes off with a little effort.


17. Remove the screws from the motherboard. Leave in the four screws that hold the fan.


18. Remove The screws that connect the LCD to the motherboard.


19. Pry the edge out slightly where it's over the VGA port.

Do these in reverse to re-assemble your EEE PC.

Everything to Everyone

Ian Bogost posted a good article on Apple's third party development policy. The comments focus a lot on cross platform development. Why?

Many years ago, some very smart people at Bell Laboratories saw a problem. When the company upgraded computers, they had to re-write the software. They realized that this could not work over a long period of time. And so they created an abstraction layer.

This abstraction layer separated the application software from the computer hardware. New machines meant adapting the abstraction layer only. Applications ported from one platform to another. Sound familiar?

The idea of cross platform development has existed for decades. All of the programming languages, frameworks, and web applications fail to solve the problem.

Learn From the Past

The abstraction layer from Bell Labs started the modern operating systems with unix. In theory, their operating system worked wonders. In practice, it fractured back into proprietary little domains. HP's unix ran on HP's computers. IBM's ran on IBM machines. And once again, the dream of cross platform withered.

A second group saw this happen. They developed a set of standards for any company calling their operating system unix. This standard is known as POSIX. Software written against POSIX work fairly well across platforms. Or I should say across platforms that support the standard.

You see, it happened again - Microsoft went in their own direction - straying from the POSIX and unix standards. The cycle begins again: proprietary split, abstraction layer, split, abstraction, etc. We're trapped in a circle because we didn't solve the problem.

Me, Myself, and I

Technology can never solve the problem. It's not a technical problem. This is a moral problem. Stop using these silly, cross platform non-solutions.

"But someone else is just going to use them, and I'll be left behind!" Thank you for proving my point. You just made a moral judgment. You cannot change anyone else's morals. You can only change your own. And you are responsible only for your own. Don't change the world, change yourself.

We are not choosing a technical solution. We are choosing a moral value system. Choose wisely.

Staunching the Flood

The question recently came up on Stackoverflow about dealing with the flood of new technologies. I ignore a lot. What makes one thing worth a look over another?

We measure any technology based on our personal priorities. What do you care about? What matters to you? I look for freedom/independence, integrity, flexibility, and stability. I values these traits in my own life. And I project those onto the technology that I use.

Know Thyself

Sounds nice and fluffy, doesn't it? I simply begged the question - how do I find my priorities? You see, everyone has priorities. Verbalizing them is another matter entirely.

As a teenager, I would read the Prince Valiant comic strip in the newspaper. One weekend found the cast on an island. The island had some magic that showed you the consequences of every decision. An old man sat in the path, knowing that if he moved a young boy would die. Prince Valiant decides to leave. Immediately he sees that decision leads to a great war - and many deaths. He stops, intending to avoid an awful future.

Another member of the party then asks the question what happens if we stay? Guess what? Great books are never written. Tyrants come to power. Society collapses. The cast then leave. And old man who lives on the island wonders why no one ever thought of that before.

The cast leaves the island because they prioritized. The very fact that you live life means you have priorities. Without priorities, we would sit absolutely still - paralyzed by an infinite number of choices.

Needle in a Haystack

How does one go about learning their own priorities? I can only share some of what has worked for me. These will not work for everyone, because not everyone is like me (thankfully).

• Take a broad, quick look at many different technologies.


• Find people like yourself, and ask them what they like.


• Quantify your reaction as love, hate, or neutral.
  

Quick, Broad Look

Like any good research project, start with the big picture. You don't need proficiency. A basic understanding will suffice. As a bonus, you will also find that this step gets easier the more exposure you have.

People Like Me

Do you know someone whose personality is like yours? Do you share several things in common with them? Find out what they value. What technology do they like? It's a great starting point.

Love, Hate and Neutral

Finally, make a decision. I am an intuitive thinker. My subconscious naturally applies all of my priorities to each technology. The first inkling of a technology's value arrives emotionally. Technologies in line with my values garner excitement. I can read about something new and walk away thinking yeah, they're on to something.

The opposite response also happens - this is stupid. Bad technologies usually have a downside. They go against my priorities.

Neutral technologies work like the name implies. They don't really bring anything new. Yet I see no reason to avoid them.

Full Circle

Now comes the really complicated part. These are not three steps. This is a cycle that repeats itself over and over. Each iteration feeds into the next.

I see a lot of career advice about looking for your passion. And almost none on how. Start looking at the love/hate decisions. What do these technologies have in common? Your passion (if I need to say it) involves the things you love. As you begin seeing those, it filters out huge chunks of the technology world. And you end with a more manageable slice.

Red Flags

During a recent interview, the hiring manager handed me a book called The Toyota Way by Jeffrey Liker. The book presents value as a stream rather than discrete points. Value derives from how much any given step moves you towards the goal. Wasting time faster reduces cost, and doesn't add value.

In Thou Shall Prosper, Rabbi Daniel Lapin highlights the spiritual nature of value. If you put these two together, then we can see that value comes from the spiritual flow of something (parts, information, etc.) from one person to another. People are the most important part of the stream! The greatest gains come from an investment in people. Change people, and the rest follows.

Dr. Liker then explains how Toyota's just in time production. Just in time means making parts just as the next step needs them. You don't build up huge inventories of parts laying around taking up space. So what happens when a machine breaks? The entire production process halts.

Imagine how much that costs? The entire production of a Toyota car stops when a ten cent fuse goes out. The obvious answer, of course, is build up some inventory to keep the rest of the line moving while you fix the errant machine. Obvious, and wrong.

The manager of a Toyota plant has an incentive for preventive maintenance. Something in the electronics blew the fuse. If he just replaces the fuse, that same machine will break down again in a day or two. And it will continue ad infinitum. The cost is down time, parts, and labor every two days for the next three years. That comes to 16,425 minutes.

Now imagine that he spends two hours fixing the broken electronics - eliminating the short. The cost is two hours down time, parts, and labor. That's it. 120 minutes versus 16,425 - which costs less?

Solve the Problem

A huge inventory hides the true cost of the down machine. Just in time forces you to confront the cost face first. In Good to Great, Jim Collins promotes red flags. They signal a problem. And you can't simply dismiss them.

Red flags hurt. Red flags cause pain. Ignoring them costs far more than solving the problem. Just in time creates a red flag. Problems simply can't fester because they'll kill you first. Consequently, you fix them. Even better, you have a measurable way of justifying the right decision. That same red flag hurts your boss too. You help them by solving the problem instead of hiding it.

So how does all of this apply to software development? It's a core tenet of iterative programming. You don't push around an inventory of nuts and bolts. Our inventory is a bit more ephemeral, yet just as real - code. The iterations create red flag moments. When the client says "that wasn't quite what I had in mind," it's a red flag. Plotting progress every day is a red flag.

Iterative development promotes public accountability. Our cost is not in minutes or down time. It's in pride and merit. When a task turns out harder than I expected, that's embarrassing. Red flag. And I don't want it to happen again. The red flag makes me want to fix the problem - otherwise it will happen again.

Why Literate Programming?

Several years ago, looking for an outline editor, I stumbled across Leo. I was a proponent of comments, comments, comments. I used this really cool - and long - template at the start of every subroutine. Spell out every variable, its purpose, and how it arrived (global, parameter, or local). Describe the return value in exquisite detail. Establish draconian coding standards and follow them to the letter. If everyone writes code like me, then we won't have this lump of spaghetti.

Boy was I wrong! Leo talks about this notion of literate programming. We read books all of the time. Why is so source code so much more difficult to read? What if we wrote code like a book?

Source code is fundamentally hard to read because we write it for the computer. Read the line again - I'll wait. Did you get that? Did you really, really get that? The structure of my code, the order of instructions, everything focuses on how the computer works. No wonder a human being has trouble - they're not a computer.

100 MPH in the Wrong Direction

Coding standards, comment blocks, and language constructs utterly fail at producing readable code. These solutions ignore the fundamental problem - we're trying to write the same thing for two completely different audiences. Imagine a classroom with PhD candidates and kindergartners. Now explain how to draw a landscape - to both groups - at the same time. Not a very successful lecture.

Source code faces the same dichotomy. Humans and computers simply do not think alike. Computers require very precise, very specific instructions. They have almost no attention span. And can never grasp the big picture. In short, computers are kindergartners.

A human, on the other hand, likes the big picture. We understand our world by association. How things fit together gives as much or more information as the thing itself. When one piece of code relates with another, that has meaning to us. The code that sets a verbose flag belongs with the code that prints the verbose messages.

To the computer, sequence matters. To a human, relationship matters. And quite often, these two views are diametrically opposed. Who wins? The computer. Because the computer ultimately runs the software. If it can't understand the source, then you do not achieve your goal. Human comprehension takes a back seat.

Then it breaks. Two years later, kapow! The client is screaming. You're sleep deprived. And after mopping up the mess, you think how can I avoid this every happening again. When debugging, human comprehension matters more.

All of this to say - we code for two audiences because we have two audiences.

Full Circle

Literate programming recognizes and solves this exact problem. You write and format code for a human audience. Then tell the computer how to reformat that same code for itself.

The language compiler translates English into machine codes. Literate programming tools translate human structure into computer sequence. You target both audiences, without redundancy.

You Have Style

Why do I like Perl? On the downside, Perl has 10 ways of doing the same thing. It enforces no particular style - so you'll find all kinds of different styles out there. The code can range from obscure to nigh unreadable. The sheer number of libraries is dizzying. How many duplicate functionality? Why in the world would I use Perl instead of Python, Java, or Ruby?

Our personalities suit us for different working environments. Some people require frequent supervision. They need a list - do step 1, then step 2, etc. Others fly by the seat of their pants, instinctually knowing the right things to do. I fall somewhere in between, leaning towards seat of the pants.

Perl fits comfortably into my personal range on the spectrum. It provides a basic structure with reasonable limits. And then opens up a field of possibilities inside of the fence. Sure, you can get to the tree by three different paths:

1. The scenic route around the hill and through the flower garden.
2. Quick - going directly over the hill.
3. Cut across the hill, overlooking the flowers yet a little more direct.
   

Perl lets outside circumstances influence your decision: performance, maintainability, readability, flexibility, quality, etc. And I like that. Not everyone does.

What's the point? Different artists choose different mediums because the medium expresses a little bit of who they are. Like other artists, a programmer chooses his medium because it expresses a little bit of who he is. You can never persuade a programmer away from their favorite language on technical merit. They didn't choose it for technical merits.