Every first year economics student learns that “there is no such thing as a free lunch”. Having taken this important lesson to heart, despite promises of powerful web services at zero cost, most publishers are aware that a payment is coming from someone, somewhere. These services require teams of developers, real data centers, and serious bandwidth. No matter how many sites widget providers sign-up, these “free” services have to be paid for, as well as provide the return that entrepreneurs and investors expect.

In some respects, the silence from many service providers on this question is completely understandable. Business models are still under construction in this space and companies have little, if any, incentive to share with rivals. I understand well the reluctance in revealing a monetization scheme, and indeed affirm that this is a tough issue. What JS-Kit has presented from the beginning, however, is that even if publishers and visitors don’t like the monetization answer, it is important to be up front about what it is.

We feel that this is especially true for competitors who might be planning to monetize the publishers’ content, visitors, traffic, SEO, ad space, or some combination thereof, once the product has become embedded in publishers’ sites. While breaking this news too early likely stifles adoption – and we get the urge to wait and grow – we are affronted by a “bait and switch” approach. In my experience, I have come to believe that “teaser services” are ultimately self-defeating. The conflicting interests they usually conceal always come to the surface eventually and, when they do, trust suffers.

The JS-Kit strategy is one of openness, rapid innovation, and great services and support while keeping focused on creating, not controlling. This strategy is not without its own risks. It requires open communication about our business model [50/50 ad revenue sharing] and straight answers to questions about control over data, users, traffic and SEO. We endeavor to demonstrate our commitments by building openness into our services themselves. We have a long way to go, but here’s a summary of our commitment to publishers and how we’re making it real.

I’d appreciate your feedback on our direction.

You control your data — Data Portability

We think publishers should not only have access to the content generated on their site [via RSS, APIs] but the ability to change providers as seamlessly as possible. That’s why we where the first third-party comment service to release “Sync” which automatically updates all new comment data directly into the blog platform in real time [Blogger, WordPress, more exist and will be announced soon]. This gives publishers the flexibility to revert, or opt-out, at any time without loss of data or risky and time-consuming conversions. We see Sync as a powerful feature in itself and as a signal that we are willing to compete purely on the basis of innovation.

You keep your Visitors — OpenID

While mobility and choice are important to publishers, they are valued by end-users as well. The era of “walled gardens” is ending and open standards for cross-domain user identification and content portability is gaining momentum. We believe that this is a good thing for sites and visitors alike. JS-Kit will unlock user accounts to a wider world by being an OpenID provider for all accounts created on JS-Kit. Of course, we support publishers’ existing login systems, but we will not force publishers into our services by offering an alternative proprietary login because we feel it only benefits the service provider by capturing publisher visitors. These logins cannot be re-used by the publisher with other services and are next to impossible to convert to a new system.

You keep your traffic — No JS-Kit Destination Site & SEO Support

Another area where publishers are rightly concerned about service providers addresses control over traffic and SEO. Many “free” service providers use the publishers very own content to entice traffic to their “community” site. These community sites offer the promise of increased return traffic yet in reality they are just vehicles to show ads or, more audaciously, offer to sell the traffic back to the original site as a lead! In each case, the publisher has traded their creative content and hard-earned traffic without receiving a penny in compensation.

Our public commitment is that JS-Kit does not provide a destination site and, if we did in future, it would be opt-in for our publishers. Our philosophy is that the “point” of aggregation should be where the visitor is, not yet another destination competing for finite traffic. JS-Kit’s newly launched Visitor Profile lets users follow whatever threads interest them, but it’s designed to bring tools and information to the community on publishers’ sites rather than siphon this traffic to a JS-Kit hosted domain. On the in-bound side of the traffic equation, publishers shouldn’t have to worry about SEO for the content that originates on their sites. JS-Kit recently launched an upgraded SEO solution that gives every publisher full SEO for the comments on their site — 100% to the publisher.

Distributed services are revolutionizing the way web sites are deployed. They drive down the cost, risk and time required to launch rich, interactive websites and enable new, cross-site and social networking applications that benefit both visitors and publishers. And there’s much more to come. Different providers have different understandings of the opportunity and of the role they should play. JS-Kit believes that the greatest opportunity lies in the role of a “trusted third party” that enables and defends the interests of both publishers and visitors. To do this, we build new services, features, business models, etc. — that avoid possible conflicts of interest and address these conflicts openly when they do arise. We’ll continue to push for respectful dialogue about issues of control and ownership and will continue to deliver technologies that win through openness, innovation, and world-class support.

Thank you for your support, 
Khris Loux, CEO JS-Kit