Andreas Haugstrup Pedersen | solitude.dk

Since 2003 I have maintained a web-based file manager script made in PHP called File Thingie. The script fills what I think is a good niché in the PHP file manager category. File Thingie is free for non-commercial use and costs only $20 for commercial use. Unlike part of the competition, I don't want to close it down and make everyone pay. The script gets very good exposure by being free for non-commercial use and I often get thank you notes from non-profit organizations or public schools who are happy that they can use File Thingie free of charge. At the same time I spend a significant amount of time maintaining File Thingie: Developing new features, optimizing the interface and handling bug reports. Because of that I feel that those who use File Thingie to make money can afford to pay me.

I am proud of File Thingie. Unlike the two obvious open-source PHP file managers (1, 2) and the commercial competition, File Thingie has a clean interface where it is easy to get an overview of your files—it doesn't have a whole circus of big bold icons that does nothing to help you find your files. It is also extremely easy to install and it is continually updated (the open-source scripts have not received updates in 1 and 3 years respectively).

But how do I get paid? Because the script is free for non-commercial use anyone can download it. As a result I'm relying on the honour system for payment. I can't tell who is using my script and they have to let me know if they are to pay the fee. Unlike Rox I can't provide positive incentives because I don't even know who my clients are. Through my server logs I can see that there are a significant amount of businesses who use File Thingie without paying. Contacting them almost always leads to no solution. The most recent example:

In the beginning of January I accidentally released a version of File Thingie that did not work in PHP4. Within 6 hours I had four support e-mails in my inbox from people who asked why File Thingie wasn't working on their server.

One of these e-mails was from Pallieter Koopmans. After I encouraged him to upgrade from PHP4 to PHP5 he told me that he would normally do this, but his current client left him without control of the server. At the same time he informed me that his company eBrain.nl had been using File Thingie for years. I politely informed him that File Thingie had never been free for commercial use and asked him to pay for the commercial license.

Pallieter felt that he did not have to pay for the use of File Thingie. He claimed that they did their best not to violate the license (untrue he did nothing, not even read the license terms or the big bold warnings on the download page). Additionally he claimed that older versions were free even for commercial use (untrue as archive.org can prove easily File Thingie has never been free for commercial use).

I of course told him that he was in the wrong, but what other methods do I have for reinforcing my license agreement? Other than asking you never to do any business with eBrain.nl or Pallieter Koopmans, of course. I highlight him because not only did he receive support from me, he also lied to my face about the state of my own software—just to get out of paying a measly $20 license fee.

Legal actions are completely out of the question as the amounts we are talking are very small (until you add them all together and they become very real). Do I force people to register before they can download File Thingie so I know their intentions? Do I raise the prices to make people take my claims more seriously? Do I put up ads on the website? Do I make special builds of File Thingie that only works on specific domain names? I really don't want force everyone to pay for File Thingie as it is very important to me that regular people and non-profits have immediate access to a good PHP file manager. Do you have a free for non-commercial use script and how do you handle payments?

Finally, I have to thank all those people who have either donated money or purchased commercial licenses for File Thingie over the past 5 years. Even when it's only a $5 donation it makes a world of difference knowing that there are someone out there who like my work so much that they are willing to send money.

Yesterday I wrote my first ever Wordpress plugin and overall it was not a pleasant experience. I have been working almost daily with Drupal for a year now and there some things the Wordpress team can learn from the Drupal developers when it comes to helping newcomers.

Wordpress does have documentation for how to write a plugin, but it is very well hidden. I bookmarked it so I don't have have to hunt for it again. Using a wiki for all documentation of Wordpress may allow for a maximum of flexibility when writing, but Drupal's collection of "handbooks" makes for a more pleasant reading experience. Drupal's API reference also comes with 6 example modules that demonstrate different parts of the system. I used these extensively when I began developing for Drupal and I missed them for Wordpress and this is something I would strongly recommend that the Wordpress community creates.

My plugin had to do two things. First it had to insert two javascript files whenever a blog post is being shown, secondly it had to insert a code generator on the page where you write new blog posts. Wordpress' way of handling both of these seem clunky and hack-ish compared to Drupal (I did make the exact same plugin as a Drupal module earlier this month).

In both scenarios you insert markup directly onto the page. In the former case by using the wp_head hook to insert the <script> elements, unlike Drupal that has functions included specifically for inserting javascript and CSS. Not a great problem in a simple plugin, but a potential annoyance when you can never be sure that your javascript file is only included once.

The latter caused more frustrations. Wordpress handles changes to the Write page in the same way—you insert raw HTML onto the page. I found it next to impossible to make the look and feel of my added HTML match whatever else was on that page. This is especially true when you use an admin theme that is not Wordpress' default one. I was able to make my code generator match the default Wordpress admin look, but then it does not look very good on Brittany's blog where she uses a different admin theme. On the other hand Drupal has a powerful Form API used to manipulate all HTML forms. For my Drupal module I simply used that to add my form elements. Using the API ensures that my form will always match the current theme, no matter what that is.

I am sure it is a deliberate decision from the Wordpress developers to have plugin developers insert their raw HTML everywhere instead of having built-in functions and APIs. The learning curve is not as steep and there is more immediate flexibility. However at the same time it becomes harder for users to evaluate the code in a given plugin—it is simply harder to decipher how a plugin does what it does and that's a Bad Thing. At the end of the day it's a matter of trade-offs and I strongly prefers Drupal's approach, even if it takes slightly longer to learn how to get started (at the very least because Drupal has excellent documentation to get me started).

There is however no excuse for Wordpress' disorganized documentation. Drupal's API reference is built directly from the comments in the code and in conjunction with the handbooks the result is a very thorough documentation. The code base in Wordpress has only a fraction of the code comments and I imagine that would make it impossible to make a “Wordpress API Reference”. This is sorely needed as many of the functions are undocumented.

In the popular “Phenomenon X Sucks” series I present: My Feed Reader Isn't What It Should Be. I like the concept of newsfeeds — that I am automatically notified when a website (or more likely weblog) is updated. The interface and integration with my browser is kind of clunky though. This is funny since the feed reader is actually integrated into the browser I use.

The reader is a part of the e-mail client, which I have been content with until I got thinking tonight. Whenever a new item is picked up by the feed reader it is archived in a folder with the rest of the items from that website. This sucks because when Vlog 2.1 is updated I have a lot of scrolling to do. I used to think that newsfeeds fitted best into the e-mail paradigm (opposed to the bookmark paradigm Firefox has gone with). But really a combination of both would be the optimal for me.

What I would like is a sidebar in my browser — and it should be a part of my browser and not a stand-alone program — like the one in this entry (I have just added some random items from my feed reader). I already have sidebars for e-mail, bookmarks, recent downloads, chat and a handful other things by default, so how hard can it be to add one for newsfeeds?

This sidebar would be a constant flow of the most recently recieved items, let's say the last 50 because I'm not going to be watching the list constantly. It would be my own personal, customizable window into the blogosphere (or the blue-cow-sphere as we say in Danish). The sidebar would simply show the title and the excerpt of each item with a link to visit to full story/blog post/video entry. There should be a small note saying which website the item is from too.

I would still have my regular feed archives because they're nice for searching, but I would prefer to use this blogosphere-window as my main feed reader. The concept of only showing new items in the archived folder for the website is stupid, because it is by default it is irrelevant which feed the item came from — I added the feed to the reader so I'm interested in all entries. Of course some people use feeds differently and have their feed reader collect items from a huge list of websites. This would be handled by being able to mark some feeds as favourites, and only favourites would show up in The Window of the Blue Cow.

And the icons next to the items? The reader supports enclosures so it can tell me what kind of content I'll be looking at (images, video, audio, porn). More on that later.