I use SVNRepository for my Subversion hosting. As a micro-ISV / contractor, I need access to my code wherever I go, so I needed it hosted and I needed it easy. I have an office downtown and I have an office in my house, and being able to periodically work from home or on the road without having my rhythm disrupted was important.  And here is where SVNRepository hits it. They set me up, sent me 1 or 2 emails and that’s it. I never heard from them again. And it’s been lovely. 

I’ve been a fan of passive software for a long time . . . you don’t always have to press a button to do something . . . but I don’t know that I’ve ever experienced a sublime service like SVNRepository before. But it got me thinking about dashCommerce and how to make the software easier to use. I’ve mentioned in the forums that the primary focus of the next release, 3.0, is on removing obstacles. And obstacles take many forms. There are the obvious ones – like requiring write/modify access to the web.config file in order to run the software. People have a hard time with that – either figuring it out, or getting their hosting provider to let them do it. And that, well, that’s an obstacle. So it’s gone.

There are also less obvious obstacles. Control is an obstacle. Coming from a proprietary software background, control is deeply embedded in thought processes around building software. And it’s difficult to let go of those thoughts as you build and develop an open source software package like dashCommerce. But control is, in fact, hurting dashCommerce, so I’ve been taking a hard look at where control can be given up and I think I have come up with something that will benefit everyone.

dashCommerce has 2 primary audiences. The most obvious are developers that use the package to satisfy the requirements of their clients and there are the store owners themselves. In either of these cases, what is most important is getting the site up and running in the fastest possible way. So as I looked at the forum posts, issues list, and my own experience with the product it became pretty clear that control of certain parts of the product may be hurting the product, or, more specifically, may be hurting the users of the product as they try to get their stores up. I receive a lot of requests for different payment providers, shipping providers, and tax providers. The problem I have in writing any of them is that as soon as I add them in to the code base, they immediately come under my control and my responsibility. And when there are issues, bugs or any number of changes that can occur when dealing with third party integrations, they become an obstacle to the successful use of the product.

So how do I propose to fix this? dashCommerce 3.0 will have a plug-in model for payment providers, shipping providers, and tax providers that will not require them to be in the code base. dashCommerce 3.0 is a full Web Application solution, so the payment providers, shipping providers, and tax providers all operate based on their implementation of interfaces, which are subsequently used by the Payment Service, Shipping Service and Tax Service. So, if you are a component developer and you wish to develop particular providers, then you’ll definitely want to check out the provider interfaces. From a developer or store owner perspective, the benefit should come in the form of widely available payment, shipping, and tax providers that will allow you to create the store you or your client want. Obviously, there will be a little ramp up time on getting the providers created, but once the train starts rolling, it should add a lot of flexibility to the product and it should get us out of your way. Removing obstacles . . . adding the dash to dashCommerce :)