Back in October of 2006 when I first launched my company, Source Tree Solutions to work full time on mojoPortal, I had kind of a fuzzy business plan with the main idea being that I would make revenue by offering consulting around the free mojoPortal product. I guess in my wide eyed optimism I thought that doing this kind of consutling would improve mojoPortal and in fact it did to some extent. A few customers actually sponsored development for things that improved mojoPortal for everyone. But most of the consutling was really for things that were not of any general benefit beyond the customer's needs, so in some cases I felt like taking on this work was actually slowing me down from progress on improving mojoPortal. Forming a business around consulting means you always have to be taking on more projects to keep the business going because you don't make any money unless you are doing billable work. Now I am in the process of shifting my strategy to sell some premium features on top of the free mojoPortal core product. I think that selling some products in order to generate revenue will be better because it will pay for the free time I need to keep improving the mojoPortal. Consulting will remain a part of my business model but my plan is to keep it very limited goig forward.
So with this changing strategy in mind I've been working feverishly to get my first product completed so that I can open up a Store here on mojoPortal.com in early July and begin selling it. The first feature for sale will be a more advanced Event Calendar that allows selling tickets to events. Following that I plan to build a Form Wizard that allows users to easily create forms to capture arbitrary data. I also plan a Fund Raiser feature and an add on package for Web Farm support. I have a lot of ideas for premium features, but my main goal is to just get enough revenue rolling in to allow me to keep improving the core. There are a lot of planned improvements for the core that I'm eager to complete, like built in support for tagging, comments, and content versioning so that they can easily be enabled for any feature with little effort. Eventually I'd like to open the store up so that other developers can also sell products there too, so that it can be a market place something like snowcovered.com which sells add ons for DNN.
One of the reasons I chose to implement a commerce enabled feature as my first product was so that I could figure out which pieces of the commerce architecture need to b re-usable. We already have a WebStore project that I will be using to sell my premium products and this WebStore is one of the free open source features of mojoPortal. So far the WebStore is very rudimentary, it can only sell download products and its really a bare bones implementation for the product catalog at the moment. The project was originally started under a sponsorship by BrainBeacon but was never completed fully because they went out of business before ever opening a store. Its hard to really polish up a complex feature like ecommerce unless you are actually using it for business or supporting a customer who is using it. So using it to sell my own products will lead to a lot of improvement in the WebStore feature. I've been doing a lot of re-factoring in the WebStore to get the re-usable pieces built into mojoPortal core so they can be used across features. For example, Country List, State List, Currency List, Language List and their administrative features were originally in the WebStore projects but I've moved them into the core of mojoPortal because they will be needed by other features. Support for Payment gateways like Google Checkout and PayPal are also being moved into the core so they can be re-used by any feature that wants to implement ecommerce. Since my first product will be an Event Calendar that allows selling tickets it will need to leverage a lot of the same ecommerce code that the WebStore does. Rather than re-implement it in every feature it has forced me to think about the best way to make most of it easily re-usable.
Implementing this more advanced Event Calendar has also led me to other improvements in the core of mojoPortal. For example one of the features in my new Event Calendar is support for recurring events. When you create a recurring event it actually creates event instances going out x number of years. Since events are also searchable using the site search, you have to update the search index for each created event as well. What I found was that creating events in rapid succession due to recurrence could lead to some problems due to the way I was handling the indexing of items. The indexing was triggered by the saving of the event then code to update the index was spawned on a new thread so that it doesn't block the UI. Under some circumstances the writing to the index was not in the proper sequence and errors could occur. So I implemented a queue in the database so that items to be indexed could be queued and then processed in batch on a background thread while keeping the sequence correct because everything is processed in queue sequence.
Another thing that got improved in the core as I implemented this new Event Calendar is module settings, which is just a place to store feature specific settings for instances of a feature. In a number of the mojoPortal features we have support for google maps, but some of the settings needed for google maps were not well supported by module settings. For example the google maps api defines some constants for the Map Type like G_NORMAL_MAP, G_SATELLITE_MAP, G_HYBRID_MAP, etc. When I first enabled support for specifying the map type, it was done in module settngs by entering the constant in a textbox like this:
pretty yucky and not user friendly since its easy to put something incorrect there and nothing to tell the user what is acceptable. So as much as this bothered me I could not conceive of shipping a paid product with this kind of setting so I implemented ISettingControl as a way to introduce a possibility to use a custom UserControl for this setting and now for all features that use the google map the setting looks like this:
much better implemented as a dropdown list! Actually not shown in the screen shot is I also implemented a dropdown for the zoom level so that it is limited to the range of acceptable values.
So, in short, developing features to sell has made me think more deeply about what is needed in the core of mojoPortal to support 3rd party feature development more easily, because its made me think more like a third party.
I haven't blogged much this month because I've been so busy working to get this feature completed and to get the store opened, but thught I should go ahead and post this to let people know what I'm doing. Several people have asked recently what happened to the store demo site as it is currently off line. I will have that site back up soon. I just have a little more re-factoring of the WebStore code to do and I will setup the demo store again.
I'm very excited about the new store opening soon and will announce it here in the blog as soon as its open. There will also be anew release of mojoPortal soon with the improvements I've mentioned above as well as a few bug fixes and skin tweaks to better support Firefox 3.