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.
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
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).
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.
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
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.
Dave - I'll second that!
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.
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?
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. :)
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
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.