Dan Heller's Photography Business Blog Industry analysis from www.danheller.com

The photography world -- the business, the culture, the art, the politics, the technology.

Site Feed

Subscribe to
Posts [Atom]

My Photo
Name:
Location: Santa Cruz, California, United States
My Books on the
Photography Business

Friday, October 09, 2009

Picscout's IRC - commenting on other people's comments

When Picscout announced its new Index Registry Connection (IRC), the blogosophere has been abuzz, and with it, personal emails directly to me requesting public commentary.

Though I'm no longer affiliated with Picscout (past VP of marketing), I feel compelled to chime in on the subject. However, I obviously have information and insight that I'm not at liberty to discuss. This is a bit frustrating because some of it would help dispel some of the myths and misunderstandings that many people have about the IRC. However, there are a few things I can say that will merely help steer people in the right direction, at least insofar as their overall understanding of the stock photo market and the IRC's relationship to that. A great deal of this is based on blogs I've posted over the years, all of which pre-dated anything Picscout is doing today.

What we know, and what Picscout has announced, is that they are in the first stages of a technology that will someday be used as the foundation for new business models yet to be discussed. Those who've expressed concern about the IRC at this point have done so based on rather erratic speculation. According to Picscout, the IRC is just an index. It's currently being populated, and they are building an API for application developers to attach to the index to get information about images. Yes, Picscout has made a preliminary prototype that uses this API -- the firefox plug-in -- but one can assume that more applications will have access to that API at some point in the future.

But this hasn't caused some unfair and somewhat simplistic criticism of the browser plug-in. It has been ridiculed as a "bad way to reach image buyers" and that "no one really wants to add a plug-in just to see who owns an image." True, but Picscout didn't characterize it that way. It's just a prototype sample to demonstrate how the IRC can work. One can reasonably assume that, over time, many third-party applications that use images -- especially those used by image buyers -- could incorporate this API as well. There's nothing secret here; this is precisely why technology companies build APIs.

There are also those who've critiqued the basic premise of an IRC. That's like criticizing Google and Yahoo for creating technology that "scans and indexes the web." As image-recognition algorithms evolve, it's natural to index images and track on the web. That there may also be an added element that points to a "licensing agent" for those images not a "good or bad" thing--it's just something people can use. It can become better or worse depending on many other factors.

For example, similar models are already in use. All major media publishers (music, film, video, and news organizations) employ some sort of recognition technology to identify their content, which is then used to track their copyrighted content online. That some of them have been used in unpopular ways is true, but it's simplistic to throw the baby out with the bath water. There are also benefits to those mechanisms; they enable device-makers and others in the supply chain to create popular and useful tools to play such content on devices ranging from MP3 players to TV set-top boxes. The ease and convenience of instant-viewing of movies, songs and other content is a direct byproduct of such technologies applied in non-combative ways.

The difference with PicScout's IRC is merely that Picscout doesn't "own" the content they crawl and index, as opposed to media publishers that only do their own content.

But there's another important difference that the IRC does that other publishers don't do -- it provides for a new pathway within the communication channel for a potential "user" to legitimately acquire arbitrary content. I spoke of the inevitability of this sort of thing back in 2007 and 2008 when I outlined business models that would evolve as image-recognition engines such as Picscout's and Idee's grew powerful enough. In fact, my entire article, The Economics of Migrating from Web 2.0 to Web 3.0, predicted precisely the kind of IRC model that Picscout has now announced.

It's true that Picscout hasn't yet announced details of its intended business models, but just like the inevitability of the IRC in the first place, there's a very limited number of business options available, each of which are similarly predictable. (I identified a variety of such models in the article above.) The real question before us is not what Picscout might do, but how well they do it. Choosing the right partners, technology back-end, marketing, and competitive differentiation will all be instrumental in their success. After all, both Google and Yahoo attempted the same technology and business models, but only one succeeded.

Another concern I've seen raised by some industry watchers is how the IRC will affect stock pricing. John Harrington's post was one of several that expressed concern over the inclusion of CC (Creative Commons) images into the index. (CC attribution allows publishers to use images for free, in exchange for credit attribution). The concern that CC images are "free" and will thereby affect market prices is mis-attributed. I've written extensively about the myths of how "free" affects pricing--you can read them in the "Pricing and Profit" section of my blog. Those articles basically highlight common and repeating events that show how open-market pricing mechanisms has a tendency to optimize price points. Don't get me wrong--there is a concern about CC images, but it's not because CC images are free.

The problem with CC images is more tied to the legitimacy of the images in the first place. This, too is something I've written about a lot before, but I can summarize the basic problem this way:
The CC is used mostly by consumers who neither understand or care one bit about the legal complexity and liability that can come from publishing CC-attributed images.
It's also the case that those who CC-attribute their images don't believe their images would ever be licensed. Lastly, CC photographers don't think about it--they just assign CC attribution with indifference, much the same way one clicks on the Agree button on license agreements for new software purchases.

It's important to recognize the mindset of people who currently use CC-attribution because it forecasts how their behaviors might change under different market conditions. And that's where the IRC comes in. If the IRC shows that people can monetize their images in ways that were previously unavailable to them, they wouldn't be so indifferent to CC. In other words, CC photographers do not universally share the political focus and determination that Lawrence Lessig has. They are not an army of political adversaries that have it out to dispense with copyright. Most CC photographers are largely unaware that they're part of someone else's agenda. The simple smell of money--of easily accessible money--will convert most CC users into regular photographer-contributors.

Because of this, I think it'd be good for Picscout--and good for photo pricing--to be inclusive of the CC community. But there's another, entirely different problem with CC that negates this advantage... for now.

The problem is, where there's profit, there's also greater incentive to game the system. As such, CC presents a significant risk. The misunderstanding and indifference by the consumer public about CC is what allows bad actors to step in. You can read about that in more detail here. The game is to give a CC attribution, and then deny that "you" are the one who gave it. Either the photographer or the user of the image can do this dishonest act. An arbitrating judge would never discern between a lying photographer looking to swindle the publisher, or a lying publisher, looking to swindle the photographer. In the event of a dispute, the dishonest player usually is the one who wins because he knows the game.

Therefore, users of CC images have to trust that the CC attribution on the images they publish is legitimate, and that's not very practical. Combine the effects of these bad actors with the social phenomenon that consumers are in the habit of attributing the CC license to any image they touch--including those they do not own--the result is a time-bomb waiting to explode: when all those mis-attributed images are used by naive publishers seeking to use "free images" through the the IRC, the lawsuits start flying.

It's not as though "most" CC images are mis-attributed. The problem is that it's an unknown number. And the risk for Picscout is that even a small number can result in a PR nightmare. If a disproportionate number of images in its index are CC-attributed, it'd be like being in a dark room full of thieves when the lights go on: you not only can see what's been stolen from you, but who stole them. If most of the goods are CC images, people learn to avoid the room if it attracts thieves. Buyers would do more than just withdraw from using CC images, they'd avoid Picscout's IRC entirely.

The same would not be said of "traditional" infringements--in fact, quite the opposite. If the large majority of the IRC index contains validated works from credible suppliers, the IRC's reputation not only goes up for the buyer, but it would attract more business partners. Here, infringement claims would be regarded as proof and legitimacy of the system.

The issue of CC credibility points to another important factor in IRC's success: managing copyright in general. First, I'll dispel the silly notion that the IRC can be used as a vehicle for easier and more frequent infringements. The IRC is not a search engine, and infringers wouldn't use the IRC if their intent is to infringe. The IRC is just used to identify information about images a human finds through other means. That is, you already have the image--you just want to know how to properly license it.

The legitimate question is whether the IRC actually helps increase licensing. And this gets to a critical point people have asked that Picscout has yet to answer: Will infringements be pursued? As a general point of interest for industry watchers, protection of copyright is one of the most critical cornerstones of copyright economics. There's a direct relationship between copyright enforcement and compliance, which itself is due to the direct relationship between copyright compliance and social norms.

In other words, most copyright infringements are because certain behaviors are regarded socially acceptable--the norm. Infringements of photography are not usually because people want to save money through stealing. To understand the economic effects of this, understand that music copyright compliance trends finally turned positive when music labels struck deals with music companies to create ways for consumers to buy music more easily. And that wouldn't have happened had the music labels not been aggressive in pursuing infringers. I address that issue thoroughly in my article, Proposal for Privatizing the Copyright Registration Process, where I write:

...there's a lesson in behavioral economics: Consumers don't fear copyright infringement consequences, companies do. Markets don't grow by educating individuals about copyright; compliance is achieved--and business grows--by creating convenient and automated mechanisms that make both access to and use of content easier. The recent announcement by Apple and record companies to remove copy protection mechanisms in songs further reflects this economic reality.


That cornerstone of economic viability--pursuing infringements--must be real and present in some form, or there is no economic infrastructure to sustain a licensing business model. What makes this problem hard for photography is that, unlike music, which is protected by music companies, the common photographer does not attempt to protect his image copyrights. Worse, photo agencies do not step in to protect images the way music companies do in any significant manner. Even large stock agencies are puppies compared to the pit-bulls of the music industry when it comes to protecting copyrights. And photo industry trade associations literally do nothing--this, compared to the recording industry trade associations that vigorously pursue infringements.

Photography infringers steal because there is no social norm dictating otherwise. Most are totally unaware that they are doing something wrong. The IRC can lead a potential buyer to a licensing agent, but unless that agent is also prepared to protect that asset, social norms won't change. And people don't build new technologies to support licensing mechanisms unless they know social behaviors will participate in that system.

While the IRC can be used as an infringement tracker, it's unknown as to who is going to pursue infringements. And that's the elephant in the middle of the room. If the culture of stealing images doesn't change, too few people will use the IRC sufficiently enough to justify investment in its growth or participation by third parties that have to choose whether to invest time, money and resources into supporting the Picscout API.

By contrast, if someone does pursue these licensing/infringement conditions, it gives incentive throughout the entire supply chain to participate. Buyers would be more diligent about licensing images to avoid infringement suits, causing more photographers to use the system to track their images, causing more agencies to get more images into the system to increase the rate of licensing, and more third party applications will build IRC access tools into their programs.

In summary, all the critiques of the IRC that I've read are premature. But that doesn't mean there aren't serious questions and challenges ahead.

Labels: , , , , , , , , , , ,

Thursday, October 08, 2009

Z-Mail is now open source

This posting has absolutely nothing to do with photography. but I have nowhere else to post it.

That said, many photographers are also computer geeks, as I once was. This announcement is a brief peek into my past life as a computer weenie.

The rest of this posting is from the README in this location:
http://www.danheller.com/zmail

Wed Oct 7 22:22:13 PST 2009

INTRODUCTION: This directory contains the open source version of Z-Mail, plus the original MUSH source code from which Z-Mail was derived. I was the original author of both programs, though not the sole contributor. More about that in the HISTORY section below.

Z-Mail is an email client--that is, a program a person uses to read email. It was, in fact, the first commercially available email client based entirely on internet protocols. In the late 1980s and early 1990s, there were plenty of free email clients for unix, but in the commercial realm, all other email programs used a proprietary networking protocol and mailbox format, and they required a gateway to connect to other email systems on the internet. Z-Mail had none of these problems.

Z-Mail was released into the open source community back in 2005 by Netmanage Inc at my request. (Again, see the HISTORY section below.) My goal in putting Z-Mail online is not to revive it. It's more to keep it alive in the public record; to create a form of historical document and to provide first-hand glimpse into the source code of a bygone era. If someone wants to use it, be my guest.

SOURCE CODE: There are several trees of the program in this archive, and they contain source code only--no binaries. The "lite" version (ozmaillite) is the source without any GUI code. That is, it's tty-only. Other than that tree, the other source trees are very similar, with the differences being minor changes introduced by individuals for reasons I am not privy to. Since I wasn't the one who did those revisions, nor do I even know who did them, I can't really say what those differences are.

One thing I've learned: the "latest" version is not necessarily more stable than earlier versions. That may be the case for some parts, but I recall instances where old code "did the right thing" under some circumstances than newer code.

Note that none of this is probably that hard to figure out for someone who truly wants to take a hack at it. Just start with the latest build, and if something doesn't work, backtrack.

Until recently, I have built and used zmail successfully on various systems ever since the early 1990s without having to examine the source code. But when I migrated from a redhat linux to a debian system this year, zmail suddenly failed to build anymore, and I found myself unable (and uninterested) in dealing with it anymore. So, I punted and resigned to using gmail.

HISTORY: In 1985, I started a software project that involved, among other things, creating an internet-based email client that had multiple user interfaces: a traditional text-based (command-line) prompt, a "cursor-driven" interface for text-based terminals, and what was then a new graphical user interface for Sun Workstations. (Sun had just introduced a more usable and formally written API for the underlying windows and graphics displays. At the time, it was called, "SunWindows.")

My mail client was called the Mail User's Shell -- aka MUSH. It's main feature was that it was built using abstract modules, each of which had program entry points from a light scripting language. This design allowed the core functionality to be separate from all its various user interfaces--text or graphical. It also made it possible plug in or out features that would allow it to be light (and diverse) enough to be portable to all UNIX platforms, as well as most any other operation system... including MS-DOS 1.1. (Yes, a 16-bit OS running on a PC with as little as 64K of RAM.)

Fast-forward five years: much interest in the program had compelled me to start a company with my then informal co-developer (Bart Schaefer) who was just graduating with his PhD from Oregon Graduate Institute and needed a job. He could have had many jobs, but he agreed to join me in founding Z-Code Software; our flagship product was called, Z-Mail.

Over the next two years, we evolved Z-Mail from the MUSH code base by adding a new GUI, beefed up the underlying core technology, enhanced the scripting language, opened up to MacOS and MS-Windows 3.1, supported various forms of POP and IMAP, and even created an extension to IMAP called Zync -- the Z-Mail Synchronization protocol. (Though the Zync server was never really released, it did address many shortcomings of IMAP that have never really been addressed since.)

Z-Mail also supported open network-based directory services, and true MIME-based email attachments. (In fact, MIME had actually evolved from more informal proposals from a variety of prototype email clients, including Z-Mail's.)

From 1990 to 1993, our program and company grew in popularity and notoriety, winning "Product of the Year" awards from various industries across all computing platforms, from PC Magazine to the UNIX workstation markets. Virtually every major corporation in the world used Z-Mail at some point, though admittedly, only a few deployed it company-wide, or beyond several thousand users. Z-Mail was most especially popular among IT executives who were stressing about their transition from local-area networks to internet-based architectures. (It takes time to force a locomotive to change tracks.)

What made Z-Mail popular was that it worked everywhere, it worked consistently, and it never crashed. It was (and still remains today) the most ported email client ever--if it had a CPU, we probably had a version of Z-Mail that ran on it. Sadly and mistakenly--and over the objection of my employees--I "sold" the company (some called it a "merger") with another, larger (and publicly traded) company, Network Computing Devices (NCD). The intention was that we would leverage their 410 employees and 65 sales offices worldwide. Alas, As many had predicted, we fell victim to the classic problem of clashing cultures between that of a more staid, publicly traded hardware company, and that of a more limber and entrepreneurial software company. I left within 3 months, and NCD had all but collapsed shortly thereafter.

Before its own demise, NCD sold Z-Mail to a company called Netmanage Inc., who at the time were in the business of selling Windows-based networking and productivity applications that ran over TCP/IP. At that time, Microsoft did not embrace the internet yet, and was still promoting their own proprietary network as the "network of the future," allowing companies like Netmanage to rake in the dough that MS didn't think existed. Among Netmanage's suite of desktop applications was their own email client, which they then renamed as Z-Mail (once they bought the rights to ours), and shelved our original Z-Mail product (save for providing support to its existing customer base).

But this wasn't to last long either, as Netmanage also fell into hard times in the years after Microsoft finally adopting the internet, both literally and figuratively. The original Z-Mail then found itself in a state of suspended animation; even though it wasn't seeing the light of day, Netmanage still owned the rights. I had lobbied intensively for five years for them to release Z-Mail to the open source community; they finally did so in 2005. (See http://www.danheller.com/zmail/netmanage-letter)

Though I had finally gotten my hands on it again, it wasn't the joy I'd hoped it to be. I had already embraced my new profession (photography), and didn't really want to put a lot of time into "relearning" Z-Mail. So, I wasn't comfortable assuming a technical lead in re-releasing it to the open source community, or of coordinating developers. Past engineers familiar Z-Mail had moved on, and my partner Bart was always suspicious of the "open-source" proclamation from Netmanage, so he wouldn't touch it either.

So, there it sat. And has been sitting. Until today.

My posting the source code here is something I should have done in 2005, but was selfishly indifferent to Z-Mail by that time. I've never been concerned about Bart's fear of liability -- I spend a great deal of time in the world of intellectual property, rights, copyright, trademark, and related matters, and I know there's no risk. Furthermore, I'm the one putting it online, so Bart and/or anyone else can feel absolved of psychological stress. No one but me is doing this.

Lastly, I'd like to give a nod of praise and acknowledgment to those who worked hard to make Z-Mail succeed, while also apologizing for my having inadvertently sentenced it to an early death. Had we waited just a few more years, we might have at least benefited from the irrational exuberance that shaped the tech boom of the 1990s. After all, if Microsoft would buy hotmail for $500M, surely Z-Mail would have gotten that much from Netscape. :-)