Do You Own Your iPhone?

Posted September 21, 2010, under CopyLeft
7 comments

There were some dark times a few years back, when big studios sued old ladies for downloading music illegally. When this failed, they have tried blocking us with DRM technologies. However, DRM was ineffective and drove customers away, so music stores mostly abandoned it.

I was quite hopeful. I thought customer demand and copyright owners have reached a new working equilibrium. I’m not so sure anymore. Consumers are in a much worse position compared to where we were twenty years ago. Once, when you bought a book, you owned it. When you bought software, you owned it. When you bought hardware, you owned it. Well, this may not be the case anymore.

You Do Not Own Your Books

Sometime in July 2009, buyers of Orwell’s literary masterpiece 1984, found that the e-book they have purchased has been erased from their Kindle devices. Is this legal? Well, it depends:

Amazon’s published terms of service agreement for the Kindle does not appear to give the company the right to delete purchases after they have been made. It says Amazon grants customers the right to keep a “permanent copy of the applicable digital content.”

However, in a lawsuit settled not two months after the incident:

In the settlement, Amazon promises never to repeat its actions, under a few conditions. The retailer will still wipe an e-book if a court or regulatory body orders it, if doing so is necessary to protect consumers from malicious code, if the consumer agrees for any reason to have the e-book removed, or if the consumer fails to pay (for instance, if the credit card issuer doesn’t remit payment).

So, the answer is still “no,” you don’t own the digital books you download. Though I can understand the reasoning behind some of the exceptions Amazon lays out, Amazon still maintains control over your e-books. It is not the same as having a book all to yourself once you leave the bookstore.

This means you do not own your books. You are licensed to read them, of course, but you do not own them. Not in the sense you were used to with our old paper books, the ones you lent to our friends.

You Do Not Own Your Software

I’ve been fuming at the mouth for the past few weeks after I’ve read this little piece on Slashdot:

A federal appeals court ruled today that the first sale doctrine is “unavailable to those who are only licensed to use their copies of copyrighted works.” This reverses a 2008 decision from the Autodesk case, in which a man was selling used copies of AutoCAD that were not currently installed on any computers. Autodesk objected to the sales because their license agreement did not permit the transfer of ownership. Today’s ruling (PDF) upholds Autodesk’s claims: “We hold today that a software user is a licensee rather than an owner of a copy where the copyright owner (1) specifies that the user is granted a license; (2) significantly restricts the user’s ability to transfer the software; and (3) imposes notable use restrictions. Applying our holding to Autodesk’s [software license agreement], we conclude that CTA was a licensee rather than an owner of copies of Release 14 and thus was not entitled to invoke the first sale doctrine or the essential step defense. “

In short: you are licensed to use the software, but it is not yours. Even if this ruling only holds for AutoCAD today, I’m sure the rest of the industry (and gaming in particular) will promptly follow suit with “improved” licenses.

You Do Not Own Your Hardware

Microsoft banned 1 million users from Xbox Live. These users were banned because their machines have been altered to allow them to play pirated games. While this it is legitimate to fight pirates, is the act of modifying the Xbox an act of copyright infringement? That depends:

“With hardware, you can do pretty much anything you want with it. There are very few rules that apply. You buy it, you own, you can take it apart, and that’s perfectly fine,” she explained. The problem is that no one simply modifies the hardware. “It becomes complicated with modern hardware because it’s combined with firmware, the embedded software.”

So, our ownership of the Xbox is partial, at best. This gives Microsoft the right to do more than ban us from the online service they provide after purchase. It gives them the right to cripple your Xbox, or even remove the software remotely, rendering the hardware useless:

Your Banned 360:

  • Cannot go on Xbox Live
  • Cannot install games to the HDD
  • Cannot use Windows Media Centre extender
  • Cannot be used to get achievements from backups without corrupting your profile

Next in stores: Apple kills jail-broken iPhones. LG shuts down TVs that played pirated movies. Toyota pulls the plug on car modifications.

Copyright as in The Right To Copy

Somewhere along the way we have lost the sense of ownership. In the digital world, every use produces a copy. Thus, every use requires consent by the license owner.

I understand the need for copyright protection by law. Piracy, distributing the work as is and wholesale possibly for a profit, is not to be condoned. I just want to point out the price we pay to keep the rights of the few protected. Everything we “buy” is actually lent to us under stern limitations (must remain connected to the Internet,  must enter credit card, must use this hardware USB device, must not sell, must not modify).

Copy rights are important, but what about the rights of ownership and property?

I’ll leave you with Larry Lessig, advocate for copyright reform and the worlds coolest lawyer:

7 comments so far, add yours ▶

Democratizing Taxes

Posted September 6, 2010, under Business, The Internet Broke It
One comment

There’s an old proverb:

Nothing in this world is certain except for death and taxes, but scientists are still trying to prevent death.

Government and taxes

Governments are a way for people to provide certain basic needs at scale. Most commonly, the services best provided by the government are those of natural monopoly: control over natural resources, electricity and water supply, roads and railroads, safety (police and army), health and education. Things that have economy of scale, where competition is ill advised, and privatization will not benefit the people.

Let’s analyze the army, as an example: the army provides security. It prevents threats to the people of this country by the people of other countries. Let’s say, for the sake of example, that the army is privatized. My neighbors pay for protection and I don’t. Can the army protect their country without protecting mine? No. Therefore, I’m incentivized not to pay, not to conscript. I leach on others. Governments are built to prevent such behavior, and it is done by taxes.

A tax is a way of collecting money from the people, for the benefit of the people through these

natural monopolies. And in order to make things easier, all tax money is pooled into one big pool, and then spread back to the different services. Through the centuries of slow information and transaction flow, this provided a certain fairness. Collecting taxes was complicated, spreading the money was complicated. Asking people what they want was complicated – even in relatively modern democracies.

Over the years, technology and changes in moral stands may change what is considered as public service and what is considered for private service, as the example of the privatized firefighters becoming popular again in the US – they will save your life, but will only save your property if you pay extra. However, the amount of control you had about how your tax money was spend was extremely limited.

Charity and taxes

There seems to be a charity boom over the past few years. I think there are two reasons for this:

  1. Increase in available income: there has been a tremendous improvement in the average quality of life over the past hundred years. Over the last decade, a lot of technologies have reached a level of maturity that we get so much bang for the buck, that there are we have spare bucks in the bank. Computers are dirt cheap, cars are smaller and cheaper, overall health is better, etc. This leaves more income for charity – because giving makes us feel good about ourselves.
  2. Internet makes charity direct: take Kiva, for example. Kiva provides you with an interface to control exactly what happens with every dollar you donate. You know who gets it, and what they plan to do with it. This is not an organization governed by a group of old people in suits. This is you helping one other person.

I think that for these two reasons, we will see more and more charity in the coming years.

There are claims that charity is the sign of bad policy. That is, if governments did a better job, we wouldn’t need charity. I think it’s the other way around. Governments were the only way we could manage the basic services in the old days. There just wasn’t any other way. Taxes are built to fit the old days.

Charity is people voting with their money on what services are important and what aren’t. What they believe should be the basic rights of every human being and what isn’t. I believe that we will see more charity-like models enter governments over the next fifty years, as democracy becomes more direct and more open than ever before.

Charitable Taxation

Don’t get me wrong – I think taxes are extremely important. It is crucial that we force everyone to partake in the payment for the public services we consume. What I suggest is a concept of Charitable Taxation, under which you will get a choice of spending some of your income tax directly to charity or government service of your choice. For example, I think most of my income tax should go to health and education services. Other may think the police is more important.

Services that are underfunded will have to change. They will be forced to become private – as it seems that nobody feels they are necessary as government services. Others will bloom, as the people feel they are more important. And what services are provided by the governme

nt will be in constant change, always adapting to the time.

There is a lot of details that need to be brushed out, obviously. I’m not completely certain that this mechanism is, in fact, stable. However, I think that we are best provided when we are more involved in how our governments act. After all, they are the government of the people, by the people and for the people.

One comment so far, add another ▶

On Websites & APIs

Posted August 5, 2010, under Code, CopyLeft, Start up!, The Internet Broke It
No comments yet

A few weeks back, I attended Startup Weekend in Israel. Startup Weekend is a gathering of people of all sorts – coders, designers, marketers and the like – that join forces for one intensive weekend to create something out of nothing. While most groups spent most of their time discussing business plans and polishing presentations (which was a disappointment for some of the more talented developers in the bunch), our team spent almost all of our time developing a new internet service.

What’s In A Service?

Developing a new service in 48 hours is not an simple task, especially for a group of ten people who have only just met and have widely varying skill sets. We wanted to take one commercial area, which we felt was badly served by existing sites, and revamping it. Creating, in two days, the open source seed that could later be used to take over the category. In Israel, the worst served segment is of classified ads, so that is what we were aiming for.

Here’s a list of what we had in mind:

  • Insert a new item (for example, a car or a cellphone)
  • Different displays and properties for each kind of classified ad (cars are different than cellphones)
  • Filter many items (according to properties of the item)
  • Search
  • User registration and login (via existing services, such as Facebook Connect)

To make things more difficult, we had ambitious goals about creating the front end of the service as well:

  • Develop not only a website, but also mobile applications (mainly, iPhone and Android).
  • Translate to several languages.
  • Test several, completely different,  design concepts and user interfaces. We really wanted to make a radically better website. Aside from the graphic design, we had several ideas about comments and Facebook integration that were pretty cool. We also had ideas about mixing UI concepts from price comparison sites as well as classified ads sites.
  • Use real ads, taken from competing sites (which, in Israel, is probably legal since classified ads are considered too utilitarian to be protected by copyright law).

The Open Website API

Building several clients to the service required extreme separation of responsibilities. In most existing frameworks (it’s slightly better in Ruby on Rails than in Django), are built on three layers: the data model, the controller or view and the template.

The data model defines what data objects are used in the system. We’ve built a simple generic model for a classified ad, and a set of meta-models that define the properties expected for each type of item.

The controller or view is responsible for fetching the data required for this action. For example, in order to create a new ad, I need the list of expected properties for this type of item (a car). The controller is responsible of all the heavy lifting (such as fetching data, validating input correctness, etc.). We created the controllers for our main actions, quite simply.

The template defines the way the page layout. It is responsible for rendering the way the website looks like (the HTML). This is what we found most cumbersome. First, each template is tied to a URL. This meant that we couldn’t have two HTML clients without splitting a lot of code. Then, the mobile client needed an API, which required a third branch of controllers and templates to render the objects for the iPhone.

This just wouldn’t do. Instead, we decided to create the API once, and use it for everything else. That means that on the server side we only had to develop the API, and not even a single HTML page. Then, we could have written as many clients as we wanted, each with a completely different flow, look and feel. The web clients were just html with some ajax, that didn’t have to be on the server. The iPhone app was just as simple to develop. No code was duplicated. I was surprised at how fast we have iterated ideas.

What’s it good for:

  • Complete API – by default, there’s an API for everything. There isn’t anything on the website that can’t be easily implemented on any other client. It makes the website very open for developers, without requiring any special treatment.
  • Complete separation of functionality from design – the server side was responsible for authentication, data validation and simple access paths to the data. The client is responsible for the flow, and user interface. Each client can be completely different, tailored for the device it is used on (think: web vs. mobile). There were hardly any limitations on what a client could do, because the API was so basic.
  • DRY code – write once, use everywhere
  • Third party friendly – having an API is important for another reason. Think of the Twitter API and how it helped create the Twitter ecosystem (something they are fighting today). For an open source website, this is an only an advantage. You want as many people plugging in and creating something new on top of it. Over time, the best ideas will merge, and community will benefit from the competition, while not wasting resources duplicating the data layer.

Cons:

  • Slower loading times – pre-rendered HTML will always be faster to load. Do people care that gmail takes a few seconds to load, every time you open it? Not really, because it’s so useful. And with smart client side caching and some clever ajax pre-loading, you can cut this time down significantly.
  • Command & Control issues – does the project include a client? If so, which one? How do you chose which client is “official”, or best? If not, does it mean you need two packages to install the website? How do you manage a list of clients? Where’s the data? Is it free and portable?
  • Security and tampering – when you have a very open API, you are vulnerable. There’s a fine line between being open, and being so open that you endanger the data integrity.

Rapid Development, Distributed Development

There are two special cases where this method can show itself to be especially useful.

The Lean Startup:

A startup in its most early stages is an organization trying to build an unknown solution for an unknown problem. It is a team of people, trying to find both a business problem and a solution to such a problem. This is called the product/market fit. The lean startup mentality dictates that the early stages of the startup should focus on learning.

Having an open website API is a great way to learn. First, it’s a great way for A/B testing and iteration of ideas. Second, there’s a real chance for serendipity. Your users will create clients for themselves, thus telling you what they need, and why they love your service.

The Open Source Website:

We’ve all heard about open source code projects, but an open source website is a much rarer creature. I’ve talked a bit about the reasons why it’s so difficult last year. The open website API liberates the project in several ways. The biggest pain point of the open source API is the data. A website without data is useless. By having the data in one central place, there’s great opportunity for innovation on the client side, having several open source clients developed with ease. In any other way, you wouldn’t be able to fork the website’s look and feel without copying all the data as well (think: Wikipedia).

I’d love to hear what you think. What other pros and cons are there? Would you want to see more open source websites?

Leave the first comment ▶

Don’t Worry, Be Happy

Posted July 19, 2010, under Getting There
No comments yet

I Worry, Therefor I Am

Our brain is a simulator for experience. Try to imagine the taste of liver and onion ice-cream. I can guess the face of disgust you’ve just made. Have you ever tried any? You haven’t. Yet you know it is a terrible idea. You can simulate the taste in your mind.

We don’t drive the simulator*. It just buzzes in our heads. In many situations, it breaks down. So we skip ahead to the first thing that comes to mind. And we convince ourselves we were so clever.

*In Soviet Russia, the simulator drives you.

The BigCo Fallacy

After a few years at BigCo, I’ve managed to earn the title of a free electron. As a free agent, untied to any particular project, I was allowed to choose what I want spend my time on. That’s a sweet job if ever you can get any.

Anyway, convinced I can single handedly code BigCo into greatness, I’ve decided to build a framework for data visualization. Clients were really hot after this type of feature, yet almost none of our products had any visualization. It just wasn’t on the road-map for any of the upcoming releases. If no one has time to develop this, I thought, I should do it. For four months I coded at my desk, testing and documenting a generic framework for a feature nobody asked for. In order to increase chances of adoption, I focused on ease of integration. If it’ll be easy enough to use, wouldn’t they just add it to the next release as a bonus? And it really was easy. You could literally integrate with it and get it working in ten minutes or so.

So, I started showing it to people. A lot of them were very excited. One project manager listed visualization as a feature, until the project missed a milestone and the feature was cut out. With a couple product managers I’ve built demos for use cases, but couldn’t get them to document their excitement as features. This happened a few times and, finally, I abandoned the framework.

A few months ago, I got a phone call from someone in BigCo. Two years after I wrote it, my little framework finally made it to production.

The moral of the story is that we can’t predict the future. We waste a lot of mental capacity worrying about the future, but usually we’re really bad at predicting it.

The Pursuit Of Happiness

There is nothing stopping us from being happy, if we choose to be. Happiness is not a game of outcomes. It’s a game of process. Apparently, there are two types of happiness:

  • Natural Happiness, when we get what we wanted and
  • Synthetic Happiness, when we don’t.

Our society tries to convince us Natural Happiness is more real, but in fact research shows Synthetic Happiness is just as real and enduring. This short talk by Dan Gilbert, changed my perspective about life. It caused me to completely change how I look at decisions.

The Influence Of Decision Making

A few tips for predicting the future and staying sane:

  • You are overestimating – in many cases, the difference between outcomes of a decision are smaller than you imagine. Your mind is geared for life-and-death situations. Run-or-fight. Modern life, not so much.
  • Limit choices – the more options you have, the more likely it is that you’ll stall the decision. Having more options doesn’t make you happy. It makes you frustrated. Since outcomes are not critical for your (psychological) well being, limit choices as often and as soon as you can.
  • Decisions are temporary (but action speaks volume) – once you have made up your mind, don’t second guess. Act. When you wait, you learn nothing. When you act, you learn plenty. Correct your course when new information comes in.
  • Focus on what doesn’t change – the long run is what matters. 37 signals said it best: focus on what doesn’t change. You may be unhappy with your job in half a year, but at no point will you ever be sorry for not having cancer. Focus on the constants (work out, eat healthier, earn enough but don’t fret about optimizations).
  • Don’t worry, be happy

Bonus Track

Bobby McFerrin, singer of “Don’t Worry, Be Happy”, demonstrates the power of expectation.

Leave the first comment ▶

How To Read Code

Posted July 4, 2010, under Code
17 comments

Scientifically Tested Code Reading Skills

I’ve run across a paper [pdf] researching how we read code. The article describes an eye tracking device that can identify what people were focusing on when they were given a piece of code. Each subject was given six snippets of code, each with a built-in error, and was asked to analyze the code and find the error. Here’s a sample from the article:

On the left, a small snippet of code that should sum numbers for 1 to a given maximum. On the right, the eye movement of the subject as he reads the code. Notice how the eye first scans the function headers, then briefly scans the function’s body and lastly focuses on where the problem is most likely to appear in real code (the loop).

Reading Code is Like Reading the Talmud

This reminded me of a very old post I’ve read at Joel Spolsky‘s blog. Joel quotes Seth Gordon which says:

The following Talmud-reading tactics are, I think, also useful for code-reading:

  1. Work in pairs, thinking out loud to one another.
  2. Argue. If your partner says “this means X”, and you either don’t understand why or you have another opinion, demand an explanation.
  3. Sometimes, when dealing with a chunk of text, it’s easier to figure out the middle *after* you understand what’s on both ends. Therefore, if a fragment of text has you stumped, try skipping over it and seeing if you can come back to it later. (But you still have to come back to it eventually.)
  4. Read the text both “inside” and “outside”. An inside reading translates the text into English (or whatever your native language is) phrase-by-phrase; an outside reading translates a larger chunk into an idiomatic paragraph. If you only read inside, you can miss the forest for the trees; if you only read outside, you can fool yourself by making broad guesses and not verifying them with details.

Seth describes two types of code. Some code is easier to read and understand first, and is the basis to the rest of the program (Type I). The second type of code is dependent of other code, and so is easier to understand in context (Type II). This fits with what I look for when I need to learn a new piece of code:

  1. Class and interface dependency: look for the base classes, which depend on no other class. These, usually, are small and simple objects, with the purpose of holding a little bit of state. They may do some calculations, but are mostly built around an internal storage and a bunch of get-set functions. These are classes of Type I. Skim through them now.
    After you are familiar with the basic building blocks, you can look for the manager classes. Most of the time there will be  a bunch of very big, hairy classes that are the core engine of the software. These are classes of Type II. Make sure you understand, from the function names, what each of these managers is supposed to do. After that, you can delve in. Manager objects usually only make sense when they interact with each other, so you have to have an idea about how all of them are designed before going into any of them too deeply. (Tip: The class called Manager is not always the manager. The class called from the main() usually is).
  2. Assume a lot: Assume that function and variable names matter. If you would have written the code, what would the GetNextIndex do? Assume it does exactly that. If a function has a name that sounds obvious enough, skip it. You’ll get back to it if you ever need to use it. Why waste your time on something you don’t need right now? There’s only this much detail you can keep in mind at this point. If you dig too deep, you’ll start forgetting things you’ve already read. Focus on purpose and structure, not on implementation.
  3. Learn by debugging: Unit tests matter, but real code matters more. If you really want to understand how the code works, the fastest way is to use it. Fire up your IDE and write a quick and dirty demo of what you wanted to use the code for. Chances are your code is bust. I’ll be surprised if you can get it to work on the first go. That’s OK. Now, start debugging. You’ll learn the inner workings of the code (and its bugs) much faster, and you’ll only focus on the parts that matter to your task.

Writing Readable Code Matters

  • Function names matter: we’ve known this for a long time, but now we know that we scan function names first. A good name, and you don’t need to focus on the implementation all that much.
  • Variable names matter: again, nothing new. Notice, though, how the eye goes back to the variable definition and assignments. We constantly look for reminders of the state of the variable.
  • Loops are the source of all evil: well, that’s not entirely true, but they are worse than all other statements. Notice how figuring out the loop is the most time consuming bit of the code. It’s where most pitfalls are (Oh, the index should be smaller OR EQUAL. Right. I forgot). Commenting can help some, but just keeping the conditions simple and readable is key. Break complexity down around the loop.
  • Short code is easier to process, so get your refactoring tools out, everybody, it’s time to split these functions.

My favorite list of tips for readable code is uncle Bob’s guide to Clean Code: A Handbook of Agile Software Craftsmanship. Even if on some occasions it gets tedious and overzealous, it is still a great read for the practical coder, dealing with many issues of writing readable code and refactoring.

Scientific Side-note

The research certainly doesn’t prove much about the way we read code, as it was only tested on 5 (that’s right – five) people. To me it seems like more could have been done.

I mean, going through the lengths of creating a really awesome eye tracking device, carefully calibrated so the machine can tell which line of code is being inspected at any moment, and then test it only on 5 people? Is getting more people into the test room so much hard work? I’d love to be a test subject and learn about my code reading habits. Next time, pick me.

17 comments so far, add yours ▶