Open Source Project Definition

My yesterday announcement didn’t gain much traction or feedback. I guess that is what you get when you neglect your blog for almost a year. It would be much better to do this with a push from the broader audience, but I guess I have to prove myself worthy of the attention. Let’s begin by defining the problem.

Problem definition

To be honest I am an entrepreneur in my hart. During my work for clients many startup ideas develop in my mind. Since I am working with eCommerce all of those ideas at their core include basic eCommerce setup: products organized in catalogs, customers can order products, payment processing, shipping processing, etc. It would be nice to focus on the parts that will differentiate those ideas from competition and leave the eCommerce part to some stable library.

Sometimes client came with request to transform their current site into an eCommerce system. Until now clients were using some well known or custom built CMS platform and they want to continue to use it. They want to keep their existing data and reduce transitional costs as much as possible. It would be a nice thing to just plug in some stable library that will hook into the existing data.

Emerging pattern in both of these cases is a need for a generic, well executed, and tested library that would encapsulate eCommerce business logic.

Project name

I thought about project name for a while and decided it will be called ecomapi. It’s nice, simple and it’s descriptive enough (ecommerce api). I registered the domain and will soon point it to my Linode instance (referal link) where all of the documentation will be hosted.

Project description

ecomapi is an open source library that encapsulates eCommerce business logic. If you look at it from the MVC pattern point of view it will represent the Model. It is designed to be embeddable into any existing system or a framework but can also be used as a basis for developing new projects. By using it in your project you can completely remove e-commerce business logic from your planing, development and maintenance phase to gain on time and resources.

Library is designed using OOP methodology and practices and consists of set of classes that allow these features:

  • Product management
  • Product types
  • Product categorization
  • Product relations
  • Catalog searching and filtering
  • Customer management
  • Order management
  • Shipping processing
  • Payment processing
  • Tax calculation
  • Defining custom business rules for order processing
  • Reports generation

Project guidelines

Development of the library needs to be guided by these statements:

  1. Fully documented
  2. Embeddable into en existing systems
  3. Flexible enough to allow usage in non-standard use cases
  4. Properly tested to assure reliability
  5. Fast (inducing as little overhead as possible)

Project goals

There are only few for now:

  1. Develop a working prototype until January 23rd, 2012.
  2. Continue with iterations until stable version 1.0 is reached.

Programming language

This was a tough decision to make and I decided to go with PHP. I really love Python and I think it’s one of the best designed platforms for development. But PHP’s much bigger audience prevailed in this case. If you consider all those WordPress, Drupal, Zend, CodeIgniter, Cake, etc. powered websites out-there that could use this kind of library, Python would not be an optimum choice. Huge barring on this decision have the fact that PHP is my primary tool at the current position.

I would also like to mention that I considered making this library language agnostic. This could be done by making the communication with the library going through some protocol (HTTP, SOAP, Custom, etc.). Reasons I rejected this idea:

  • Library is a more general case. User can add which ever protocol they want on top of the library if the need comes for something like that.
  • It will turn project into a specialized server. Users will have to deal with setting up the server instead of embedding the library into their project and knowing it will work.
  • It will add another layer that will increase possibility for errors and bugs, it also needs additional testing.
  • There are speed considerations. Library calls will always outperform service calls.
  • Last but not least target audience for this project doesn’t have a need for something like that.


On this page I set some of the crucial elements of the ecomapi project. Without farther delay I will start with concrete organization and implementation process to validate my assumptions about this project.

In the next post I will explain the work flow of the project.

Leave a Reply

Your email address will not be published. Required fields are marked *