The Future of MT-Notifier »
Recently I have received a number of comments about how MT-Notifier appears to be working fine, and then suddenly stops functioning. The most often factor in this change is a larger number of subscribers. That is to say, things are working fine with a few subscribers, but as that number increases to hundreds, so to do the apparent failures of the system.
Let me say that I don't know what causes this. I haven't seen the problem personally, and I know of at least one installation that has a very large number of subscriptions that continues to work fine. This would lead me to believe that it's a resource issue. Specifically, I think that much of it may have to do with the use of the PluginData table.
This table is designed to store settings in Movable Type. That is, to allow a plugin to keep some information that it might need to access later. It is my opinion, due to recent incidents, that this table is designed for basic settings only. As the size of the table grows, the processing of the table becomes much more inefficient and eventually just seems to stop functioning altogether (in reality, it's just really, really slow).
Unfortunately, adding a number of subscriptions to MT-Notifier then has the effect of killing the notification function. When it began, the MT-Notifier record was relatively simple, but as features have been added, the storage has become more complex, contributing even more to the problem.
Please realize that this is purely conjecture. I've done some work on other systems, which were very overloaded because of the use of PluginData (though not specifically with MT-Notifier) and removing this table from the equation has fixed the issues. I have not looked at any of the systems that are reporting problems, but because of the (increasing) number, it seems as likely an explanation as any - especially when nothing else has changed in the interim.
Where does this lead? To the next version of MT-Notifier. I have planed for a while to create separate tables for MT-Notifier to use, as that will speed processing dramatically (as well as significantly lessen the complexity of the code). That's not really the issue.
The issue is that I am having an increasingly difficult time dedicating time to the development (and, more specifically, maintenance and support) of plugins. I'll be straightfoward with you - much of it is because there is no financial reward in me doing so. As such, I need to do things that generate income, and I have a difficult time putting those things off in favor of something that does not do so. I hope that makes sense to most of you.
That leaves me with a decision to make about the future of MT-Notifier.
One option is to run a Dropcash-style campaign to raise a particular amount of money. This is probably my least favorite method, because quite frankly the amount would be so large that it wouldn't be worthwhile - essentially I'd be charging for my time up-front. With little idea of the specifics involved, I'd probably estimate that effort pretty badly. Even if I was accurate, the amount would probably be somewhat prohibitive.
The second option is a form of licensing. There are at least three ways to proceed with this. One is a smaller licensing fee for all users. The second is a free "personal" version, with inherent limits and then a third option is to only require licenses for commercial users, with higher fees being charged. Because of the management issues involved, I'm leaning towards the first option. First, the fees are smaller - meaning more licenses. Second, I don't have to worry about managing two different versions, or figuring out who is and who is not a commercial user.
The third option is to provide the software for free but require a subscription of some sort for any support issues. This also appeals to me, as it means that if you can use the software as-is, that's great. But if you need help installing it or getting it to work or troubleshooting or whatever, that will cost. Others could provide this service as well, which diminishes the appeal to me - why pay my rates when you can pay someone else much less, for instance.
The final option is to simply not develop MT-Notifier any longer and let someone else take it up (if they should be interested in doing so). I believe that it is licensed in such a way that this would be doable for just about anyone, whether I decide on this avenue officially or not. This requires me to give up my "baby". Not sure how I feel about this option.
As a result, I think I'm leaning mostly towards a small licensing fee per installation. But I'm not sure. I realize that many scenarios require a payment of some sort. That's the point. I am at a point where I cannot dedicate the time without some form of financial reward involved. That means either that needs to happen, or I need to move on to other things. I'm curious about your opinion. Any thoughts out there?




















Comments (28)
I would suggest an upfront fee to purchase and then a yearly maintenance fee.
The downside of that is, you'll need to create some kind of registration key that prevents unauthorized copies from being used. You'll also have to keep track of who's current on their maintenance plan and who isn't.
Posted by Ted | March 26, 2005 7:36 AM
I have a number of clients that are running what I would describe as "MT article and comment post-processing plugins". I'm thinking primarily of MT-Blacklist and MT-Notifier.
A few of these clients have pointed out intermittent problems with the completion of all processing steps that the plugins are supposed to take. The most typical problem experienced is when MT-Blacklist forces moderation on a comment but fails to notify the blog's owner by email.
Problems like this have never happened to me on my biggest weblog, OperationGadget.com.
The difference between the configurations that my clients are running and that of OperationGadget.com is that Operation Gadget runs on a dedicated server at a major hosting provider while my clients' configurations are typically much less expensive shared hosting environments where processor resources are limited.
It sounds like the problems with MT-Notifier that others are reporting may also be related to the length of time that the notification action takes to run. Is this the sort of "resource issue" that you are referring to in your post?
--Dave Aiello, WeblogImprovement.com
Posted by Dave Aiello | March 28, 2005 9:22 AM
Yes. Consider that if the subscription records are stored in an actual table (with individual fields for each piece of data), then any method used to access the records can handle the paticulars of the query - for instance, loading all records belonging to a particular email address, for instance.
If you use PluginData, then the entire MT-Notifier data structure is stored in a single field (technically, in two fields, because there are two types of records). So if you want to process only a portion, it must process every record, find those that match, and act only upon those.
As people are finding out, as the size of that table (and the data within) increases, that becomes much more inefficient. I believe that using individual tables as necessary will not only eliminate this problem, but vastly increase the performance of MT-Notifier.
Now MT-Blacklist actually uses its own tables - so that may or may not be the issue with that install. But PluginData is definitely a drag on performance, and I'd like to eliminate it as an issue. This would also open up MT-Notifier to more users (ie, those that don't have PluginData functions, perhaps because they don't have Storable installed).
Posted by Chad Everett | March 28, 2005 9:30 AM
Incidentally, part of the MT-Blacklist inefficienty probably comes from the fact that each comment (or trackback, I think) has to go through each pattern you are using to check for spam. As that list gets larger, it takes more processing. If this is an issue for you, you may want to consider using something like MT-Approval and/or MT-Moderate, that aren't checking the content. For your smaller customers they may work out better.
Posted by Chad Everett | March 28, 2005 9:36 AM
I'm using Bloglet right now for my 1000+ member mailing list that goes out almost daily. Can you help me set something up that is better than Bloglet?
Thanks, Dennis
Posted by Dennis Crouch | March 28, 2005 4:43 PM
CHarge for it! Are you kidding? $10 to $20 through a paypal account is nothing and you have given us a great product. However, you will need to make sure it works properly and you have the table issue you described resolved. If it works, people will pay. If it doesn't you will pay. In time and effort.
Posted by Dave Merwin | March 29, 2005 9:22 AM
Dave - I'll second that!
Posted by dave | March 30, 2005 7:23 AM
Charge a fee for subsequent versions.
I believe people are willing to pay for a product that is reliable and supported. I know I will.
If you feel strongly that you would like to continue offering users a no-cost option, perhaps you could continue to provide the current version as a free download. Offer it unsupported, and just alert users that they may run into performance obstacles if they, say, use it for a list of more than a few hundred addresses.
Posted by jespes | April 1, 2005 7:40 PM
I've just found and installed MTNotifier on a shared server in less than 10mins. Configured it and up and running in another 5mins. Problem? None. Would I pay for it? Absolutely.
As for the worries about managing subscription for users, registration of genuine copies, payment, downloading of product etc, you shouldn't need to worry about things like that.
You can sign up to any number of people such as Element5 who will handle that part for you (for a fee, but something worth paying when it keeps you developing and them handling the dark side).
Do you have an idea of the number of downloads or installs of the free version have been made in the past?
Posted by Chris | April 17, 2005 8:59 PM
Chris, MT-Notifer has been downloaded 2037 times since version 1.4.1 was released slightly more than a year ago (I didn't keep track prior to that). Of those, 1762 are downloads of version 2 or higher, which I entered into the plugin contest. I'm sure it's been distributed more than that as a part of the plugin pack.
Element 5 is a good idea, but if even 1% of the people who download the software also register it (that's about 18 people on version 2), it's just too much effort. What's more is that I believe 1% to be a pretty high number. There are only 9 comments on this thread about the very topic, and two of those are mine!
I think what I will do is rewrite the software using integrated tables. I'll release the basic notifier functionality as a free version, and then figure out what to do about the rest of the functionality - more specifically, how to distribute it in order to realize something of a gain on the software.
Perhaps a subscription of sorts, allowing access to all other features for a particular period (ie, 1 year). Sort of like others do with upgrades. It will definitely take some thinking on the subject, but what I really want to do is to make a bit of money from it, so I don't feel quite so bad spending the time it takes to create the software and support it, while also minimizing the time I spend keeping up with it. That's the sweet spot that I need to find. :)
Posted by Chad Everett | April 18, 2005 4:41 PM
Whatever you intend to do, I wish you the best of luck.
If there is anything I can do to help out feel free to ask via email.
Best regards
Chris
Posted by Chris | April 18, 2005 5:25 PM
I'd be more than willing to pay for an MT-Notifier that included instructions on how to add a checkbox for subscriptions.
Sadly, configuring templates is simply beyond me. :)
If the instructions for adding the "subscribe to these comments" checkbox were included in the package, I'd be first in line with my dough.
Best (and thanks),
C.
Posted by Craig | April 19, 2005 4:22 AM
Hi Chad,
Would it be possible to design the plugin so that up to say 10 people on the mailing list it worked and was free; if you wanted more than 10 would would be directed to a website to pay for and upgrade to the unlimited version?
Posted by Elise | April 20, 2005 9:41 PM
Hi, I absolutely love your Notifier. I have one question though.
I had a friend that wrote something similar which relied on a cron job and well it worked beautifully but was quite difficult to update or make any changes to it. There is one feature to it that I would love to see included in Notifier. It's an option to delay sending the notification for XX number of minutes. I often will post something and within seconds of posting it will update the post. I enabled the feature on Notifier to send the full text of the post and have disabled sending notifications each time a post is updated. Is this something you'd consider introducing as a feature? Maybe something in the options that allows the owner of the blog to set the number of minutes it waits before sending the notification. I usually had mine set to 60 minutes before it would send the notification of a new post.
Just an idea.
Tommy
Posted by Tommy | May 9, 2005 9:15 PM
Tommy, that's an interesting idea, but may be a bit more challenging to implement - notably because Notifier doesn't run via Cron or some other scheduler, but within the save process.
It might be possible to "submit" a job to run a predetermined time later, similar to the background job function of MT - but since this doesn't work on all installs, I'm going to assume that some hosts won't allow it. That would make it difficult.
Still, it's an interesting idea. Thanks for the suggestion.
Posted by Chad Everett | May 10, 2005 5:49 AM
I've got MT-Notifier installed, which is kind of embarrassing because I'm not clear on something... Does it send out the notifications automatically when I update, or do I still have to hit the "send notifications" button?
Posted by Mac Thomason | May 10, 2005 3:31 PM
MT-Notifier works automatically when you save the entry (or comment). No need to click anything. In fact, you don't have the option to click anything - the "send notifications" button works with the Movable Type notification system, which is different than MT-Notifier.
Posted by Chad Everett | May 10, 2005 3:36 PM
Thanks. I wasn't sure because I didn't get the notification myself.
Posted by Mac Thomason | May 10, 2005 6:31 PM
Being needy again... Is there a way to send full entries rather than just an excerpt?
Posted by Mac Thomason | May 11, 2005 4:51 PM
Yes, but it requires hacking the code. Check the comments of earlier MT-Notifier releases. I'd say 2.4.3, but it might be 2.3.4 (or something else entirely). It's definitely since version 2.0.0.
Posted by Chad Everett | May 11, 2005 4:57 PM
I've got an issue with the comment email that Notifier generates; specifically, when a user receives a notification, in the body of the email, the "Manage Subscription" link is written as:
<pre>
Manage Your Subscriptions:
test123@webboi.net:" target="_new">http://www.Webboi.net/cgi-bin/blog/mt-notifier.cgi?akey=test123@webboi.net:
e2fQjMEmrAtwI
</pre>
Obviously, since the syntax of the url is not correct, unless the user knows which part to copy/paste into their browser, it will send them to an invalid page. How would I overcome this malformed url?
I welcome your feedback.
Rob
Posted by Rob | May 20, 2005 3:34 AM
Hi Rob -
MT-Notifier has never included any <pre> tags of any sort in any location, nor has it included any "target" specifications within the notification.tmpl (the one which sends email) or in the code to send such notifications, so I can't tell you where this is coming from. Have you changed the notification.tmpl file at all? Is it in the right location (tmpl/email)?
If you are interested, I'd be happy to help find the problem, but I would charge you for such support if it turns out, as suspected, to not be related to MT-Notifier. Please let me know.
Posted by Chad Everett | May 20, 2005 5:45 AM
I had to tweak mt-notifier's /tmpl/cms/view_log.tmpl to include the magic token gizmo for mt3.16, otherwise all attempts to reset my activity log received the dreaded error: "It appears you changed your password... Log out and back in..."
changed line 31 to this:
<form><input type="button" onclick="window.location='<TMPL_VAR NAME=SCRIPT_URL>?__mode=reset_log&magic_token=<TMPL_VAR NAME=MAGIC_TOKEN>'" value="<MT_TRANS phrase="Reset Activity Log">">
FWIW, thought it might help other users encountering this error. :)
Posted by kate | May 21, 2005 9:17 AM
Hiya! I love the idea of this plug in... but the scalability issues scare me. Any progress since march?
Posted by Nick Aster | May 23, 2005 4:09 PM
I recently upgarded from 3.11 to 3.16, decided to download Notifier 2.5, and what do you know. Everything works, nothing broke all is well and I would be happy to pay (preferably a one-time fee) for this plugin, as I believe it is an invaluable means to make my project's blog (a small press) super-sticky.
Thanks and hope to see some improvements soon (if you can find the time!)
Posted by Daniel Sendecki | May 28, 2005 5:11 PM
The option is there now. Just $24 per license.
Posted by Chad Everett | May 28, 2005 5:17 PM
As to the scalability issues: I've been working with The Leaky Cauldron, and their subscription base of over 26000 works fine. Is it the fastest solution in the world? Probably not. But it works, and it doesn't appear to have any problems. This is the largest (and busiest) installation of which I am aware.
This doesn't mean there won't be another release - just that it isn't for scalability issues. Future releases will enhance the speed and functionality.
Posted by Chad Everett | July 7, 2005 10:43 AM
Just wanted to add a plea to see if you can update Notifier to work with Mt 3.2 - it doesn't work with beta 3. Some of the changes are minor - for example the password file has been integrated into the config file, so notifier dies looking for that.
Posted by KO | August 9, 2005 5:28 AM