I’ve recently been provoked to take a serious look at Kaplak again. I thought I would drop a few lines in this place to announce that I’m back to work on Kaplak – if only in a tiny slice of my time – but no less ambitiously.
The truth is I’ve never really left. For various reasons, it made a lot of sense to close down the company Kaplak and focus on other things, but I’ve never quite left the ideas we worked with in Kaplak, and I believe the world still needs what we had coming for it. In the meantime there’s not much else to do but figure out ways to build upon the experience we had then.
So in the back of my head, this is what I have been doing. I am right now on three months of parental leave from work – which among other things, have lent me some long-missed time to think about the meaning of my life and the connected world. When teaching one does actually do a lot of thinking – but it’s mostly about teaching and planning classes and lessons, and not much else. Since August 2009 I’ve been teaching history and media full time at Aabenraa Statsskole – and since the summer of 2007 I’ve also had two kids (one now aged 4 and one nearly 9 months), which in sum means that my life is totally different today than what it was when I first started Kaplak.
So what did provoke me to take yet another long arduous journey to the far far away land of the slim ends of the long tail? (Plural because they come in large numbers!) Among other things, I’ve come across a couple of online phenomena which deserves a few words in this space.
Earlier this year Google launched Google+ which I have embraced and played with – at times enthusiastically, at others somewhat reluctantly. It’s like Friendfeed has come back – but different and with a whole new feature-set, which combines the best of what Twitter and Facebook have to offer. But it’s still a proprietary monster, where Google (among many other things) gets to decide what their users are ‘allowed to call themselves’, simply because while Google+ empowers users to share their stuff in ever more flexible ways, the network is still owned by Google and this ownership is never in question. Nevertheless, the ease of sharing stuff on Google+ has made me into a regular poster.
Google has been quick to add hashtags to it’s service, and I’ve now begun to add hashtags to my stuff, which makes it easy to find #copyfight stuff and posts on #landvaluetax, as well as all those #thingsthatmakeyouseetheworldjustalittlebitdifferently. It often has stricken me though, that I ought not to use Google to make what is in essence niche micro sites much like the ones we were developing with Kaplak Stream. Instead, I’d like to share stuff using WordPress as a platform as we did in Kaplak, and only use Google+ as a secondary channel.
If this then that
Just recently I stumbled (via my Google+ network) across an online service which goes by the name If This Then That, which stirred up a lot of thoughts about Kaplak in the back of my head. Occasionally I come across something which contributes a piece to this ongoing puzzle. Ifttt, I believe, is such a piece. Now these stirred-up thoughts have fallen into place again, and although a lot of the ideas we worked with in Kaplak remains (making a sound business out of less-than-popular (“long tail”) products – and transforming work life and the universe as we know it in the process), some have landed in new places.
My instinct tells me that Ifttt (and similar services) paves the way for the future of the internet. Ifttt truly empowers users because it puts users in charge of the what, when and where of their online activities – not the services they use. It widens a door already opened by the APIs of online services, which adds a new parameter to the equation. Companies such as Facebook, Google and Twitter will increasingly have to compete on how well they serve the needs of users to bring their data where they need them to go (and in that process make more data available flexibly and cater to the needs of services such as Ifttt) – and not where those companies would like them to go.
Now, what does this entail for Kaplak?
We had two working strategies in Kaplak – one was widgets, the other was Kaplak Stream. Both aimed at the same target : selling niche products in rich niche contexts, which would easily be found by their niche customers, and in doing this connecting seller with buyer. The middleman – the “skipper” making the connection, would in turn earn kaplak, a percentage of the product value given by the seller.
Now, it’s a top priority to concentrate efforts on making Kaplak economically feasible. This means, that with the greater ease and the less hazzle we can create these connections, the better, as the turnout (kaplak) from each sale must be expected to be very small. Therefore, we will focus on the “stream”-approach, but with a few decisive changes to make sure we must do as little “clean up” and maintenance as possible – more on this at a later time and place.
This aligns well with what my life looks like right now. Among other things, I can not dedicate as large a portion of my time as I would like to build up Kaplak, at least at this point in my life. I will keep teaching history and media, and continue to devote a large part of my spare time to my precious family.
But what I do have, are those spare minutes during the day, which cannot be used for much else. I will continue to cruise the web and share stuff, using my phone, my laptop and my PC. But increasingly I will ‘share with Kaplak’ i.e. develop a sharing platform and work out posting routines accordingly, using Kaplak – rather than use Google+ just because I am too lazy to use my own platform. Google+ has other excellent possibilities and uses – but should never be the end destination for shared stuff, no less so than Facebook or Friendfeed should.
Using services such as Ifttt we can easily distribute items to their proper place, and since I’ve last worked seriously with WordPress, useful and valuable plugins such as FeedWordPress has only improved – and will assist to help create the niche sites, which in turn will deliver the helpful contexts for future Kaplak products.
What is important though, is that I sense that it is in fact possible – right now, using the tools that we have right now – to build a site architecture, without the need for a lot of coding, which will (if very slowly, to begin with) help accomplish the beginnings of what we set out to do with Kaplak.
We’re both inside companies and outside them. The boundaries that separate our conversations look like the Berlin Wall today, but they’re really just an annoyance. We know they’re coming down. We’re going to work from both sides to take them down.
I agree. I experience these annoyances on a daily basis. Sometimes I have to really constrain myself not to let go of my temper, because I feel that our insights in many ways far precede our abilities to apply these to practical use. For instance, I cannot understand that while I do 95% of my banking via the internet, most banks do not put 95% of their ressources to work to give me as a customer the best possible online banking experience. Even less would probably do. If they just put 80% behind it, that would probably suffice. But they don’t. I am also annoyed when I have to communicate with my daughter’s doctor via an online form which permits only a limited amount of characters, largely because they do not trust email as a means of communication. In fact, I am always annoyed when people who presumably wants to communicate with me, don’t let me communicate back on equal terms. I find that arrogant. As far as possible I resist their attempts to control the way in which I should communicate with them.
The rooms in which we speak
Architectures are important. They are the ways we construct the rooms in which we speak. The “conversations” of The Cluetrain Manifesto take place within the framework of such architectures. They have names such as Facebook, Twitter and Google. Other such architectures are called things like WordPress, Joomla, MediaWiki, Firefox, RSS and GNU/Linux. They have a tremendous impact on the ways we communicate online, on the ways in which we filter our incoming information streams, and on the ways we enable new connections and enable new ideas to reach others, and enable their ideas to reach us. As important as architecture is, so more important is ownership : that we claim ownership to the tools we use. That we claim ownership to the channels and the walls that decide who will learn to know us, who will receive our message, and who will be filtered out, who will not. We decide what walls are torn down and what are built. With the web and simple tools we can, and we do.
Many of the software architectures that we employ, from the webserver and webscripting functionality of Apache and PHP to the popular self-publishing power of tools such as WordPress, are free software. I.e. built and easily adaptable by anyone who wants to adapt them for particular purposes.
Other architectures are walled gardens, maintained by organizations and companies, who are not concerned about the choice of their customers. While companies such as Facebook, Twitter and Google offer greatly useful applications to their customers, their services impose limits on their use. In short, they choose to remain in control. They choose not to release the source code. Not to let their users adapt the tools they’re offering to their particular purpose.
If a company such as Facebook or Twitter goes bankrupt, users will lose their data – no compensation, no anything. There’s no obvious way to retrieve data from these services, and since the code is not free, one can’t write tools to retrieve those data by oneself. While most of these services offer useful and advanced interfaces so that programmers can access their data from the outside, the service stays in control. You can’t obtain access to data they don’t want you to obtain access to. Facebook ultimately decides who they like to write applications for “their” platform. Twitter abolishes user accounts at their whim, because ultimately Twitter decides. Ultimately, Google decides to pull the plug on a GMail or YouTube account, on grounds they choose, not their customers.
These walls of proprietary ownership are the Berlin walls of today. We meet them everywhere, when we are annoyed we can’t do certain things with the tools we use. When we communicate within the confines of architectures that we do not own and do not feel comfortable with, because they disallow us to be ourselves. In the worst case, we hit them head on when we find that our account on some service has been abolished unfairly, with nothing we can say to get our data back. When a service ceases to be in business, a product ceases to be supported, or a new company policy is enforced in spite of what we feel about it.
So how are these walls going to come crumbling down?
As I do here and have often argued, the only way we can operate freely in our online environments is if and when we ourselves are able to create, adapt, control and empower the architectures that we employ. We need our software and online services to be as easily adaptable as any article on Wikipedia. Wikipedia is enabled by the clever use of a particular architecture in combination with a copyright in reverse known as “copyleft”. The GNU Free Documentation License (GFDL) license ensures that every contribution to Wikipedia’s articles can be freely adapted and re-distributed by others.
Until now, free software have also relied on copyright. Similar to Wikipedia’s license, the General Public License (GPL) which is commonly used for most free software projects ensures that the code stays open and can be manipulated by anyone, no matter who distributes or sells it.
But free software need not depend on copyright. The greatest barrier to the spread of free software is that so many do not understand why it is important. Too many business executives cannot see, that it is as beneficial to them as to their customers, that they facilitate their customers’ ability to change and adapt the code. Too many organizations do not understand that releasing their source code opens up new, decentralized, flexible and less costly ways to organize their activities. And too many internet users (myself included) are too convenient with their habitual uses of proprietary online tools to question deeply and realize what’s at stake. We also find time to be a scarce good, since we also have to work to pay our bills – often inside companies led by execs who don’t “get it”.
How things look from the inside
The free software movement is “working on the outside” to bring down these walls. But on the inside, every Facebook, Google and Twitter employee is also an internet user and customer. They are people who talk using these same tools, they have other lives, they quit and start their own businesses, in short they engage in conversations where they go (or are allowed to go, by their companies). What limitations in ownership are put in place by their companies also limit their ability to deliver the best possible product, the best possible service and the best way to help solve their customer’s problems. They are equally annoyed by the corporate walls put in place beyond their control.
There are two great problems which faces the walled corporations, now and in the future :
1. They will increasingly encounter free architectures and services, which may yet perform poorly, but have much greater potential to outgrow and outperform their proprietary competitors.
2. As clever candidates everywhere discover their own ability to build and employ free architectures of their own choosing and flavour and adapt them to suit their own particular purposes, companies will find it increasingly harder to find qualified candidates to fill positions. What’s attractive in working under the command of a boss, if you can work for yourself? What’s the attraction in working for a company, whose business model is not adaptable to the open environments spreading on the web?
What if Facebook went GPL?
In closing, let me speculate aloud to show an example of the business landscape I believe will replace the walled gardens of today’s corporate environment. Among many online applications, Facebook is probably the service with which I have the most problematic relationship. There’s no doubt in my mind that Facebook does something very well : it helps facilitate connections and conversations. It helps me get in touch and stay in touch with family, friends and business contacts who wouldn’t otherwise read my blog or relate to me via other online tools. It works really great for friends you don’t see a lot on a daily basis, but still want to stay in touch with. But for all it’s merits, I hate the fact that I can’t easily search and access data in Facebook. I dislike that I can’t extract the information I need with RSS from my Facebook archives, and that I cannot play even further with the category layers, to adapt the service even further to suit my needs.
Let’s imagine that Facebook decides to go open source. Facebook releases it’s source code and invites developers to join in and contribute to the code. They still are leading the development of the core Facebook application, but also offer anyone a downloadable package, which can be freely modified and redistributed. Anyone is free to fork Facebook and set up a rival site.
What would happen then?
First, we’d fix everything that is wrong with it. We’d add RSS feeds to all the places where we’d like RSS feeds. We’d work to make what’s going on transparent, so that we could learn from it. And we’d make those changes publically available to anyone, who’d like to take a look and use them for their own purposes.
But what I think makes Facebook really brilliant as a free software package is the way it can adopt external applications within itself. Facebook as a general purpose communications platform is great and extremely adaptable. This makes it well suited as a platform for almost any corporate website. Most companies need to enable conversations across the organization, with suppliers, customers, investors, and everyone else slightly related to the company. The fact that most companies’ employees already spend a good deal of time using Facebook during work hours shouldn’t lead to abolishing and blocking Facebook from office computers, but should rather be seen as an encouragement to take this brilliant tool and give it a form of their own choosing. If Facebook was released under GPL, that would indeed be a viable option.
Adopting Facebook as a corporate platform would not only allow employees and customers to communicate on equal footing, it would also allow them to create applications for the platform, which would help adapt the package in very particular, employee- and customer-centric ways to suit the company’s purposes. That the package already has proven so scalable on a global level is a testament to it’s robustness in even the most trying of corporate environments.
But even if Facebook is not released under GPL, we’re already well on our way to build, use and sustain software like this, and many businesses do build their own social networking architectures. In fact, many CMS packages which are free software already implement features which mirror the successful features of Facebook and other social networking services. For WordPress, we already have BuddyPress, a prebundled collection of plugins which convert a WordPress installation to a fullblown social networking site.
But businesses and developers will continue to get it wrong, if they do not offer their employees, members and customers the same freedoms by releasing their source code, as they had when they chose to base their solution on free software.
In the long term, the question is, if Facebook and other proprietary businesses will still have a business model, if they do not give up control and release their code? If they do not enable the free adaptability of their software, chances are, with time, we’ll just build our own.
There are several voices in this broad discussion, and to characterize some of the perspectives :
Commercial developers and start-ups, who need a way to make a living from what they do : create WordPress plugins and themes
WordPress users who demand more features and ever more clever ways to personalize and customize the software they use
Open source developers who feel cheated when what they’ve spent hours and hours developing is “sold” by others
Purists who feel that since WordPress is free (GPL’ed as well as free of charge) every component based on or rooted in WordPress ought also to be free
Pragmatics who tend to say that as long as the GPL is respected, developers may do anything with the code, and that plugins which are developed from scratch are not necessarily born GPL’ed
I think this is a crucial discussion for the future of open source and “free” software.
As far as my understanding of the GPL goes there’s nothing wrong with redistributing GPL’ed software, in fact this is the point of the license. The only condition is the software remains licensed under GPL or a similar license. That receivers in your end receive the same benefits that you had, is a key component of what is usually referred to as copyleft.
There’s nothing wrong with charging money for the redistribution of this code either. Noone says anybody should provide stuff for free, just because it is GPL’ed “free” software. What the freedom in “free software” means is that anyone who obtains the code also remains at liberty to redistribute the GPL’ed code and charge for it too, if he or she wishes to do so. We all have expenses, and there are all kinds of good reasons to ask money for the time and work we put into providing a service or a product to someone else.
The tricky thing is, that since users who buy a piece of GPL’ed software also has the full right to redistribute that software, the business model appears to be broken. It may not actually be broken, since there are many good reasons to pay to receive benefits with the software “purchased”. Someone who obtains a piece of GPL’ed software via a bittorrent network, won’t get the support and imminent future updates that someone who “bought” the software from the developer does. But if we toss this aside, that the business model appears broken is probably what leads some developers to pursue proprietary business models.
Now, there’s a perfect match between supply and demand in the users who wants new features and are willing to pay for them too, and the developers ready to supply new features. It appears pretty straightforward. It’s good for users and it’s good for developers, who make a living from what they do. Right? Wrong.
The advantage of using GPL or any other copyleft strategy is that the process of redistribution and refinement can easily be facilitated. If or when a useful feature is included in a version of the code, it can be adopted by the source developer or anybody else involved, so that everybody gains, whether they charge for it to others or not. It can facilitate the creation of a community around “the project”. The software is improved by community developers, and eventually the code or project may leverage much more than any individual developer is capable of.
If you use a proprietary model as a developer you’re shutting others out. As a proprietary developer you have to build your entire organization around the fact that all problems must be solved in-house or paid for. You’re in the business of constructing a costly operation, which must be paid for. In contrast, the free software developer may not have a great income from his work (someone in the linked discussion said he had received 50$ in donations at 20.000 downloads), but also has few expenses and obligations. Once a website has been set up, he can begin to facilitate the distribution and development of his project because it is GPL’ed. This of course doesn’t do it alone, but if it isn’t out there, it won’t be used and improved upon (for free) at all. If an open source developer has 20.000 downloads, it means his work is popular and things are working out. He ought to wake up and find a way to leverage all that traffic and interest to create even better software, which will attract even more users and reach even greater markets. I find open source developers are typically not very good at this, and there are no easy recipes for how to make it work.
My point is, however, that even while it may not seem so at the surface level, you’re in a much worse position as a proprietary developer, than the open source and free software hobbyist, who is capable of inviting global input and value to his work by using the GPL and has very few expenses doing so.
Now, what about the user? At a first glance, users get what they want, a theme or plugin of their choice and style. But the price they pay is not simply the money changing hands. They also become dependant on a company or a particular developer to provide for them the code and support they want. If the user becomes dissatisfied with the company’s service or the company goes bankrupt, or if the developer decides to go his own way leaving the product and it’s users behind, few will relate enough to the product to be able to pick up where he left. If a piece of code has had 20.000 downloads globally, it becomes a lot easier to find someone, for whom this piece of work is not just a strange mess. But it is also possible, for a user who can’t find somebody to help him, to dive into the code himself and learn to solve problems and create new features, and then redistribute his work.
I’m really great with developers selling their work, but I believe they’re shooting themselves in their feet, if they use GPL’ed software in the first place as a platform or market, and then do not use the powerful legal tools at their disposal in the GPL and other free licenses, to leverage the reach and further refinement of what they do. And I believe users who are too impatient with open source communities and hobbyist free software developers and pay for themes and plugins help trap themselves and their developers in closed circles, which will lead them nowhere while the open communities grow stronger. There’s a real danger however, that great developer talent will wind up in these kinds of dead-end relationships, which doesn’t expose their projects to the open scrutiny of global free software communities. There’s also a real danger that open source software projects won’t spawn the businesses and startups they need, in order to create thriving communities and cultivate collaborative efforts to create even better architectures for facilitating the development of great free software. This may happen if developers and startups decline from using the GPL or other copyleft strategies, out of the misunderstanding and fear that they can’t make money on something which is “free”.
I too have made a similar but better plugin called YAAB-Autoblogger. Yaab has all features of wp-o-matic and in addition it can create automatic blog carnivals in your site. Also it supports SMS blogging and Youtube cloning. Ebay product syndication and automated content rewriting are upcoming features. After all I myself is a doctor ( not a programmer ). I started making this plugin for my personal use, but when I doveloped it, it was highly impressing and I have planned to release it for public. Kindly download it from http://www.psypo.com/yaab , try it and if possible please review it in your valuable blog
I have only just played around with this plugin a little, but it looks fairly promising. Here are my initial comments and feedback for further improvement (which I also posted on Satheesh’s blog) :
I can’t get YAAB to fetch multiple posts in separate posts, like FWP or WP-o-Matic does. It fetches only the latest post or saves the complete feed into a single post, no matter what values I provide it with. I’m sure this is easily fixed or explained.
YAAB is very userfriendly and has an almost cartoony tutorial-like quality. I like the little character who helps guide setting up a feed for aggregation. Neat stuff, but it makes me wonder how flexible the plugin will be for more “unusual” type feeds.
I also like the template very much. It’s very similar to what Guillermo did in WP-o-Matic, and I liked it there too :-)
However, there are no variables for author, date posted, permalinks back to the source, or other data included in the feeds. Would be nice to be able to extract all the information in the feed, and place it where I want in the post. Also would be nice to have a regex like functionality to replace terms or code in a feed item, like the one used in WP-o-Matic. But especially the author and source/permalink information is crucial, IMHO.
There are no functionality for tagging incoming posts, or fetching the tags included in the feed. Also a bit crucial in my book.
As previously stated, I have absolutely no idea how flexible this plugin is yet when it comes to feeds from Twitter Search and other such weird Atom sources. But as this is the first version, I’ll worry about that later :-) Keep up the good work, Satheesh!
Thought I’d share a few notes on the things we test in the Kaplak Labs these days. Kaplak Labs is simply a WordPress based site in our WordPress MU powered setup, on which we test themes and plugins before we employ them on other sites. Right now I’m preoccupied with setting up a filtering process for Kaplak Stream. This filtering process aims to sanitize feed items and add some stuff to each item, which improves it’s chances for survival in the stream :
Retrieve all tags/categories from posts and create new tags/categories if they don’t exist.
Semi-automatically tag/categorize all feed items. Sometimes feed publishers don’t tag/categorize posts very well, and even a well-tagged/categorized item may have new meaning in a different context. We use the Calais Autotagging plugins for WordPress to do this, for the time being.
Convert all categories and tags to categories only, to keep things clean and simple. We actually treat categories as tags, though. Because WP categories is the more widely used functionality of WordPress of the two, we’ve decided to go with categories over tags.
Add link to the item source directly in the feed item content, to make sure (sort of) that it stays with the unaltered post when it is fetched and possibly re-published from the Kaplak Stream.
Cache all images locally to improve performance and avoid traffic spikes on source sites, when subsequent sites fetches images all way back from the source. Kaplak Stream hosts all images (for which we will probably be using Amazon S3) to ensure their availability for all sites which fetch items from the stream.
It should also filter out spam and duplicate items. We still have to sort out however, what happens if an improved version of a post gets fed back into the Stream. Ultimately, we’d like users to be able to tag and categorize items according to the contexts they use them in, and be able to retrieve these back into posts in the stream.
In the process of setting this up I discovered Yahoo Pipes, which looks like a very useful tool taking in an amount of data (in a feed format), manipulate it and spit out a new feed. Experimented a bit with it, and found it a bit tricky to actually create something useful, but will no doubt give it some further attention. We may be able to use it for something.
Great to see this round of improvements! Some of the most important features seem to be support for tags and formatting filters. The plugin has also been removed from beta status and supports all the latest versions of WordPress (2.5 and 2.6).
RSS feeds are published for individual, private consumption; they are not a blanket license to, or waiver of, reprint rights. Taking and republshing content—no matter how much or how little—without the original author’s permission is a violation of U.S. and international Copyright laws. There are exceptions, of course, detailed in the Fair Use doctrine, but such exceptions are very specific and do not apply to the vast majority of sites using FeedWordPress, Autoblog, and the like. In fact, Charles Johnson, the creator of FeedWordPress is in constant and frequent violation of copyright law because the apparent majority of his blog’s content is stolen without the original authors’ permission.
In that case, Google, which enables users to very easily tag and share (i.e. republish) feeds they find interesting via their popular service Google Reader, is guilty of same said constant and frequent violation of copyright law, or at least, in willful and assisting infringement. The same of course goes for YouTube and any web service, which allows anyone to embed their videos, images and games on your own local site.
Who says a tool has to be used in one way only? Let’s get creative! That’s how problems are solved and new business models are developed!
To be honest, I’m not a big fan of people scraping content that people have sweated over. However, one thing I don’t mind doing is thieving from thieves.
You’re on the hunt for “disposable” content – generally not text based. Think along the lines of Flash games, funny videos, funny pictures, hypnomagical-optical-illusions – that kind of thing. The Internet is awash with blogs that showcase this stuff. Check out Google blogsearch and try a search like funny pictures blog. There’s hundreds of the leeching bastards showcasing other peoples pictures, videos, games and hypnomagical-optical-illusions for their website. They can hardly call it “their” content. With this ethical pebble tossed aside, we can go and grab some content.
There’s loads of ways you can hunt down potential content. You’re on the lookout for RSS feeds with this rich media. So you could try; Google Blogsearch, Technorati, MyBlogLog – basically any site that lets you search the blogosphere.
My personal point of view (this is also Kaplak’s stand) is that the problem of visibility for sites and products is larger than the largely fictional problem of “theft”. If you make syndicated feeds publicly available, you implicitly want and ask for syndication, because you want your message out. Syndication will help your site or product become visible in places and contexts it would not otherwise be seen in, and that’s why you use it and why you should use it. If you do not want your message out in other contexts and do not want to see your articles appear on other websites in a syndicated format, you can simply choose not to make articles available for syndication. The benefits however, in the Google Juice and traffic which syndication brings back to your sites and products, are in most cases much greater than the disadvantages.
Accusing syndication sites and services for theft and copyright infringement is IMHO ridiculous at best, as these services actually help your site become seen and achieve better rankings in search engines. It helps your interested readers and users find you in the first place. And if you don’t want to be read – why publish to the web?
At worst, these allegations are harmful, as they instill an atmosphere of fear and create distrust of using RSS, feeds and aggregation tools. Instead, we need to urge and encourage syndication and use of syndicated feeds, as it enables rich web contexts, which would otherwise not be possible, and makes it easier to direct interest and relevant traffic to sites and subjects of interest. It is above all a tool, which can be used for our mutual benefits – or for spamming and creating yet more “get rich quick” mentality kind of sites filled with stuff the world could care less about (but apparently doesn’t). I am of the opinion that these types of sites may provide their owners with short-term rewards, but ultimately will fade to authentic sites of much stronger lasting value. How to build lasting value, and help these sites and products build lasting value, is what we’re interested in here.
Preparing a battle plan for integrating WordPress µ (or MU) with our network of sites. I will commence the execution of this plan at a non-disclosed time sometime in the near future. The Kaplak Blog and Kaplak Wiki will remain online but the site in our root will be completely removed and therefore unreachable. This in effect terminates the old Kaplak site in favour of a complete WordPress µ install. We will work from there to rebuild the root site with new texts and the subsite network reachable from subdomains to kaplak.com, which will be known as the Kaplak Stream.
I’ve never done an install of WP µ before. I’ve performed lots of installs of web software before, but I have no prior experience with µ. Installing web packages I’ve usually taken the backups I felt were necessry but otherwise simply plunged ahead and learnt from my mistakes. I’ve always learned to prepare mentally for a one way process of steep learning dotted with the occasional tumble, which makes me spend days beforehand searching for other users’ experiences. A little planning and knowing the road ahead doesn’t hurt. So I’ve spent a lot of time these past days reading up on other people’s experiences and problems, to get an idea about what to expect. Unfortunately, what we’re doing with µ doesn’t seem to be the usual thing – so we will no doubt learn things the hard way, either way.
Here’s what the general plan looks like right now :
1. Install WP µ package in our root
2. Create the pages we need to make the root site functionable
3. Create the initial round of subsites we need for archival purposes. Every external service we use will be set up to feed a site of it’s own. I.e. all of our bookmarks will be archived from delicious, all our tweets will be archived from Twitter, and so on.
4. Install and make sure WP-o-matic (or another appropriate automatic RSS feeder) is acting up to speed. WP-o-matic should be fully compatible with WP µ.
5. Feed our archived streams back into one major subsite channel, which will be the Kaplak Stream, as well as to other subsites to which they are of interest.
This completes our first setup and the site is functional. It only starts getting interesting, though. Next, we generate any subsite we wish at a particular time by feeding it the appropriate RSS lumps of interest. For this work we will use Google Reader to begin with, with it’s built-in tagging option, which makes it easy to generate new feeds from existing RSS feeds. Each subsite aims to sell preferably one product only, or a very limited range of products. To begin with, these will be products made available via affiliate programs such as (but not limited to) Amazon Associates, eJunkie and RedAntenna, depending on the product. These sites need not be popular, nor updated or visited frequently, but will seek to stay highly focused on their subject of interest, in order to offer as rich a context as possible when they are visited, commented upon or linked to. This makes it easy and valuable for related sites and communities to tap into these streams, as they build up lasting value.
The waters are divided these days on the blog commenting service Disqus, which we’ve also installed here on the Kaplak Blog. Personally I was impressed with it when I first saw it on the How To Split The Atom blog, and decided it could do great work for the Kaplak Blog too. So when we moved the blog, it was a natural step to install their WordPress plugin.
What Disqus does is deliver a cross-blog and cross-platform commenting plugin for blogs, which hosts and connects comments, and feeds them back in different ways to the blogs. There are several great advantages from this ‘fragmentation of blog comments’, and so far about 4000 blogs (according to Disqus) think so too – and there are some apparent drawbacks, at least for time being.
I’ve been trying to gather the pros and cons of Disqus as it looks right now, and ultimately I am pretty undecided. Robin Good, blogger and new media reporter (who, among other things, did a remix of Steal This Film) sums the undecidedness up pretty well in this video :
To sum up as they’ve been put by Robin and others recently :
Users who comment on different blogs can easily find their comments again and organize their discussions.
Users are much more able to interact with other bloggers and commenters, independently of the blogs they comment on.
Bloggers can easily reply to comments via Disqus email, which saves a lot of ‘logging in/out’ hazzle if you receive many comments.
Discussions can be feeded easily from Disqus into other services, such as FriendFeed, drawing other people into following discussions and commenting.
Bloggers potentially lose out on the income from ads, if too much commenting activity is moved from “their blog” to Disqus
No support for trackbacks or pingbacks, which is a pain, since these play a vital role in the blogging “if I link to you, you link to me too” ecology. Daniel Ha of Disqus says they’re working on something big in this department. One can’t help but wonder, though, if they foresaw what kind of a dealbreaker not including this to begin with could be?
You can find Kaplak’s Disqus Community page here. I’m curious to learn more, as I am still pretty undecided. All things balanced out, for now we keep Disqus on the blog – even though we might use a temporary hack to enable WordPress trackbacks. In my current estimate the social benefits and effects of using Disqus are greater than the Google juice we get from comments (we don’t get a lot of comments yet), although it is a difficult estimate, since we are a young blog and needs to attract readers. I guess it adds up to this : why can’t we have both the Google juice and the trackbacks, as well as the great social functionality and effects that Disqus can give us?
How does the balance look for you and your blog or commenting habits? What are the scores, advantages and benefits? What is the dealbreaker?