Content Owners Seem to Hate and Love YouTube (mostly hate)

Today, I read news that Viacom has ordered YouTube to pull down 100,000 videos that allegedly violate their copyrights. I don’t get it.

Clearly, the problem is that nobody truly believes free online exposure is a good thing. And you know what, perhaps it isn’t always. Nobody knows right now because the idea is not tested enough. Here’s what happens.

  • The content producers makes something cool, such as the Colbert Report, sells some TV ad spots, and puts it up on cable. They reap the rewards.
  • Then some no name punk comes in, strips out the commercials, and puts the entire show, for free, on the Internet.
  • This gives viewers a chance to see the show without turning on the TV, thus avoiding the ads.

At least this is how Viacom and other major producers see it. And in response, many of large networks have put up their own crappier sites that host the content infused with ads. But for some reason they can’t fathom, no matter how hard they try, it fails to catch on.

They blame YouTube for this. And subsequently start the lawsuits. But YouTube isn’t without blame here. I can’t speculate on what has been offered, but I can see some very important features that need to be in place before a major content producer signs up:

  • The ability, much like on videos on, to have limited fast forwarding so you can’t play a particular segment of a video without first viewing the ad for that section. It’s a reasonable restriction that most consumers will not mind.
  • Copyright detection software going live.

A while ago, it was speculated that YouTube had some copyright detecting software coming up. Well, here’s how it should work:

  1. Viacom uploads a video with ads into the special sponsors section of the website
  2. It is encoded with a special filter that watermarks the entire video
  3. If anybody else re-posts the video on YouTube, the content is automatically flagged, taken down, and the user is suspended.

Let’s see some compromise here.

No, Viacom, people are not demanding free content. No, RIAA, people who pirate aren’t doing it because they hate paying for music. The point is, the market is demanding content be online and in an easy to access, less restrictive manner. People will pay for this. It may not be the arm and leg some producers are hoping for, but with the reduced distribution costs and elimination of some middlemen it should be a sound idea to at least attempt the transition.

So what is with all of this all or nothing bullshit? It can’t work. If you give everybody nothing, people will have a greater motivation to circumvent your rules. The crowd has spoken, and a single content producer’s website will never gain real traction with the video viewing demographic because people want to be able to go to one place to quench all of their video watching needs. Viacom can’t fight a tsunami of Internet democracy – something the RIAA/MPAA have proven damn near impossible even if you sue 10,000 people.

RSS Tracker Images

I use Google personalized homepage to track the latest and greatest news. Google recently unveiled a new feature that puts a little plus next to stories. When you click on this plus, the article description slides out underneath.

So I clicked on a feed from CNN and noticed two blank image placeholders appeared and then quickly disappeared. I noticed this was also the case for my Slashdot feeds. So I examined the raw RSS feed on Slashdot, and noticed this:

<img src=”” border=”0″></img></a></p><img src=”″/>

In other words, whenever the feed is viewed by a reader that supports HTML (most readers nowadays), a 1×1 pixel image is displayed from the Slashdot server. This allows the server to track where feeds are being viewed from as well as any other information they can scrape such as your IP, the time, if when the feed was pulled, your username (on Slashdot), etc.

This technology is widely used in e-commerce for tracking clicks that lead to sales. While this is an obvious step, I had never really heard about this until now.

One unintended consequence of Google’s reader is that the pixel only fires if I click on the plus image. This means CNN et al. is able to determine if a particular viewer who looks at a description is more likely to come read the full article. It also means the pixel only fires by active user intervention, making the tracking feature largely useless. But then again, if users pinged 25 servers every time they loaded up Google, I think a lot of servers might begin to have problems. 🙂

If you didn’t already know of this, I hope this was an interesting read.

Using IE7? Test in IE6 with a Stand Alone Browser

This is old news to some of you. In fact, I’ve known about this for many months now.

With the introduction of IE7, testing for IE6 compatibility issues has become a real pain. I would know — I encountered them when redesigning this site.

Anyway, there is a stand alone IE6 download at which works flawlessly. Simply download the ie6eolas zip file, extract it, and run iexplorer.exe. It’s great.

Programming Contract Work Tips Part 2

In my other article about contract work, I gave general tips on what to watch out for when defining a contract. This article will:

  • Discuss intellectual property concerns most of you probably never even thought of
  • Give tips on how to build your portfolio if you are just starting out as an aspiring web developer
  • Expand on points from the previous article based on the feedback I received

This article is geared heavily toward web developers and will no longer apply as readily to other types of technical contract work. For example, for design related contract work, it is very common and standard that you own no rights to the works you produce (such as a logo) whereas such a point is not always the case in web development. Nevertheless, I tried to keep things generalized so more people can benefit from reading it. 🙂

Intellectual Property Concerns

  • Before anything else is hammered down, negotiate for joint ownership of the code that you will write. This isn’t always possible depending on your client, but I believe this is worth discussing. If you do not state this up-front, and don’t have a written record of the conversation, you just did work-for-hire, which means you own nothing. I am talking about retaining copyright. They retain ownership of trademarks, trade secrets, or patents they already own that you might leverage during your contract. You’re really only interested in the libraries, not the implementation portions (non-class/function files). Clients won’t – at first – like the sound of this whole “sharing” of rights business, but in reality, it means they can distribute and modify your code any way they please. It affects you because you are able to use snippets or libraries without liability in future projects. If they are not sold at this point, I always point out that the reason I am able to promise them faster development with less buggy code is that I have a well-tested library from past jobs that they will be benefiting from. Frankly, if they still can’t accept the idea of a mutually beneficial agreement, I move on. But most clients usually don’t care after I make that last point. Again, this will depend largely on the type of client you are dealing with (big bad corporations versus mom-and-pop-shops).
  • Make sure you have a discussion with the client about open source software (OSS). Remember that you can’t promise that they can keep the application proprietary if you use certain OSS licenses. Make sure they understand the ramifications of you incorporating OSS into the code (i.e., they may have to distribute the source). If you are developing a web application, this will likely not be a concern. If they don’t plan on distributing the code you write, this won’t apply either. Remember that there are many open source licenses out there and that one may suit their needs (check the MIT license).
  • Even if your client approves of using OSS, decide on your own if that is a good idea. Know the differences between the various licenses. Typically, I avoid licenses that “infect” my entire code base when I am only using a library. As such, I try to stick to licenses like LGPL when I’m using libraries. This is so that I can retain 100% ownership of the code. Please, respect license terms of code your borrow. 
  • Always remember to add your signature in the source code, especially in libraries. This is so that future maintainers can contact you and disputes about ownership can be proven. This would include:
    • Your full name
    • An email address
    • Licensing or copyright terms, if any
    • Date
  • Make sure they own and register any domain names. You do not want to be bothered or responsible for owning their trademarks!

How to Build a Client Base – Web Developer Style

I had a fair amount of success when it came to getting clients long before I had my first programming job, and without any prior experience to show for it. This section is for aspiring developers hoping to gain experience and build a client base at the same time. Here’s how.

Disclaimer: Before I say anything, understand that contract work will not be a full time job, or even pay rent, for some significant amount of time until you build a client list and a decent portfolio. Many people keep contract work as a side income.

  • Partner up with a designer. It’s best if you know this person in real life. Agree that you will split the pay 30/70 on sites with little or no coding, and 70/30 on database applications. The work won’t always be 50/50 or even 70/30, but it will help both of you build your portfolios, which is critical for mutual long term success. This is a fair deal for anybody starting out. Also, agree that you each own 100% of your parts of the project, but retain rights to claim the entire finished product as something you worked on. Picking a good designer is crucial.
  • Now ask friends and family for anybody that needs a website, and do it for cheap. Here’s the catch that will help you get the ball rolling: if this is your first job, offer to do an entire site, with two design drafts, for only a couple hundred dollars (my first one was $250) with free support for a reasonable timeframe (a month). But the catch is that they must allow you as much time as you need. Almost anybody will take your offer. This is awesome for you because you are able to essentially learn and work on a hobby project at your leisure, but then get paid at the end! Make sure you do it in a timely manner (under 6 weeks).
  • Choose your first project carefully. You will underestimate how difficult a project is. Do not, under any circumstance, agree to do a full content management system, forum, ticket system, or other heavy database application. You might finish it some day, but not without a ton of frustration and lowered expectations. It’s your first project: start small and grow organically. Try to do them a company or personal website that has a comment form, PayPal order system, or other relatively simple concepts. The moment you try to duplicate a major commercial product as your first project, you should realize you are probably shooting yourself in the foot.
  • Each time you complete a project, up your rates by a hundred dollars. The beginning is slow, but if you are good at what you do, you will receive new business in no time. Eventually, you will start to see what your market hourly rate is.
  • Part ways with the designer once you complete half a dozen projects, but stay in touch. Hate designing, but the job pays well? Sub-contract it out to your designer buddy! Is the job 90% design work? Just give it to the designer and take 10% of the pay for your part! The point is, you can each build up your own client lists while maintaining a mutually beneficial relationship with someone you have a proven work history with.

Closing Points

  • On getting things in writing: all communication should be done over email. If something is said in person or over the phone, always follow up with an email confirming what was said. This goes back to the idea of having things in writing. Email records will act as evidence if you have a dispute. It’s a clever way of making sure everything is in writing without needing signatures and lawyers.
  • On getting paid: host the code on your servers until full payment has been received. Don’t develop on their servers unless you really trust them or need the development environment. This is because underhanded clients may try to screw you. If you have all of the source on your servers, in a worst case scenario, you spent three weeks writing a cool application on your free time to add to your portfolio. If they screw you, keep the code and make sure to give back any money they fronted you.
  • On getting feedback: when web-developing, always start with a mockup. Create some basic HTML pages to show the client. Keep it bare and ugly, but functional. Tell them to ignore the ugly look, but instead comment on how the page looks like it would work. Are there the correct input boxes? Are all the fields there? Are all the pages to be expected in place? You will use this mockup code later when you fill it in with real processing code. I can’t stress the importance of this development concept in terms of saving yourself time. Oh, and keeping it ugly will force them to pay attention to the stuff that matters: functionality.
  • On aligning their expectations: after you pass the 85% completion mark, begin focusing your attention on how it works, not what it can do. Clients may initially judge your product by how it looks, but in the long term, they will judge it by how it works. This is different from what it can do. You might make the most advanced car ever made, but if the driving experience sucks, next year’s model will not sell. It’s the how, not the what. Non-programmers will always choose “easy” solutions over “difficult but more functional” ones. Just look at the iPod. When trying to figure out the user interface, always ask yourself, “Is there a better, more intuitive way to present this so even my mom could understand what this page does?”

As a side note, I am a developer today, thanks largely in part to my early contract work. It taught me a lot of important skills about managing deadlines, predicting development timelines, and interaction techniques with clients. Most of all, I graduated college with real stuff under my belt, unlike many of my peers who only had homework assignments to show for their experience.