Coming Soon - The mojoPortal Store

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 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 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.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.



re: Coming Soon - The mojoPortal Store

Saturday, June 28, 2008 4:07:50 PM


I was speaking to a friend of mine the other day who uses online forms to conduct surveys.  To build these forms he has  an account with a company that provides a browser based form builder and data collection service.  As you probably know, there are a number of these firms around at the moment, all  offering similar capabilities.  My friend is very particular in his requirements though, as one of the input controls he favours is a slider control to allow the user to set a percentage value. and he has only found two firms that offer this.  If you are going to offer form creation capabilities, it might be worht adding a few widgets that other peole don't offer in order to differentiate your product.

Hope this helps

re: Coming Soon - The mojoPortal Store

Sunday, June 29, 2008 7:47:38 AM

Hi Alastair,

Thats a good idea about including a slider control type. I will definitely do that.



re: Coming Soon - The mojoPortal Store

Monday, June 30, 2008 8:31:06 AM

I think a free and open core is good and you or anyone else making money off of contols is even better.  You could even resell for or advertise other control developers.  You've built a good core and used some really good partners for parts of it.  I can't wait too see what stuff I can buy in the future.

James Mansion

re: Coming Soon - The mojoPortal Store

Monday, June 30, 2008 10:27:05 AM

I doubt you'll be the last to find that the puff about selling consultance on the back of open source is a pretty useless strategy unless someone else writes the open source software.  Which is odd because it seems pretty obvious to me.  As you say 'wide eyed optimism'. Good luck with the new proprietary stuff.


re: Coming Soon - The mojoPortal Store

Monday, June 30, 2008 3:07:22 PM

I guess it's a good way to success.

But there is a danger that the core assembly will be overloaded with code not used by 90% of modules and as a result, it'll work more and more slowly and take more and more memory. mojoPortal is a unique product as it can work with Mono on *nix and supports so many databases. And as I can see no product can do it so well despite some commercial hype. I think that for all this to work should exist a pool of quality third-party modules.  So the commercial approach should help it a lot. As Mono and Moonlight improve, there will be a competitive edge with already solved problems.

re: Coming Soon - The mojoPortal Store

Tuesday, July 1, 2008 2:16:13 PM

Hi Bob,

Yes, I will be very careful to find the right balance of keeping mojoportal light weight but also providing things that may be commonly needed across features so that they don't have to be re-implemented in each feature that needs them. At some point I may move all the features except the Html module out of the main web project. Not separate projects for each feature as that gets unwieldy too but kind of a core bundle of features that can be left out if desired so that the main web only has html feature and whatever custom features someone wants to package with it. This way developers who want to package their feature with mojoportal but not as a broader content management solution, more focused on just their apps, they will be able to do this by leaving out a lot of the main content features.



Comments are closed on this post.