Open Source Strategies

A blog about open source software and business models, enterprise software, and the opentaps Open Source ERP + CRM Suite.

Friday, October 26, 2007

The Limits of Open Source

There was an article this week in InfoWeek entitled How Linux is Testing the Limits of Open Source Development which really hit home. In many ways, it's reflecting some of the issues that our much smaller opentaps Open Source ERP + CRM project is going through as well, and it made me realize that there may be a natural, self-correcting mechanism which limits the growth of open source projects.

Let me give you an example of how I think this works: Imagine a really smart developer sat down and started an open source project. She starts writing code, and pretty soon the software is useful. More and more people download it, and soon some other contributors/developers show up. The rate of development increases, and more features show up, leading (hopefully) to more developers. There's a positive feedback loop until the bugs also creep up. Eventually, if the bugs aren't contained, the software will become so unstable that new users would stop using it. Then all of a sudden, the project stalls out.

What to do? One logical answer is just to shrink the project down, fix the bugs, and get it stable again. This may mean the project has to be smaller, but that's no shame--open source should be about having fun writing great code, not about which project is bigger.

If, however, the project is trying to solve large-scale problems, then it must create an infrastructure similar to that found at commercial software development firms:
  1. It would have to invest in documentation, so that both users and developers know how the application should work.
  2. It would need to invest in a large amount of unit testing and recruit human testers, so that new features don't break existing ones.
  3. Above all, it must create and enforce a common code culture, so that every developer could take over code written by another developer.
Such an infrastructure is necessarily less "efficient" in the sense that the lines of net code generated per developer would fall, because developer time would be taken up testing and reviewing. It also may be less fun for some developers to be reviewing code, enforcing standards, or devising unit tests rather than writing cool code. (Believe me, I tried to put it off as long as I could--but I can't any more.) Finally, it's hard for open source projects to turn away features or enforce standards. Somebody is so nice that he wants to contribute a new feature. Do you really want to hurt his feelings by saying "Your code doesn't conform to our standards?"

However, having observed several large scale open source projects up close, I'm convinced that there is no alternative if you want to build large scale open source software. We're going to have to make documentation, testing, and standards an integral part of our development process at opentaps if we want to scale up our development and deliver the features our community needs.

Bookmark and Share

Monday, October 22, 2007

The Importance of Good Error Messages

The following is a true story:

A few months ago, I wrote my mother-in-law a check. A couple of weeks later, it was returned to me with a letter from the bank which said: "Instrument is not negotiable."

I had absolutely no idea what that meant, so I took it, with the check to the bank. The teller had no idea, and neither did the branch manager.

Finally, a young trainee said "Oh, I know! We went over this last week in training." She then pointed out that a check is a negotiable instrument if it has five things filled in: name, numeric amount, written amount, signature, and date. In my haste to pay my mother-in-law, I forgot to fill in the date on the check.

For all you software developers who want to say "those banks are so #!@@^* !$%*^", let's try to do a better job of explaining what our software does first.

Bookmark and Share

Wednesday, October 03, 2007

opentaps Quarterly Update

As the opentaps Open Source ERP + CRM community continues to grow, I will try to publish a regular update to keep all our users, contributors, and services providers up to date with our progress.

Recent Developments

The past few months have been a period of significant changes in opentaps. By incorporating several new open source applications into our core framework, we are now positioned to transform opentaps from an ERP application to an enterprise-wide application platform. The new opentaps 1.0 will offer a full range of capabilities, including mobile connectivity and a choice of open source business intelligence tools, on top of our core ERP and CRM features.

Some of key developments include:
  • Integration of the Funambol Data Synchronization via the Spring framework to allow users to share contacts and calendars between opentaps and mobile phones and desktop applications such as Outlook and Evolution.
  • Integration of both JasperReports and Pentaho business intelligence suites into opentaps.
  • Integration of FCKEditor for web-based email and marketing applications.
  • New tools for integrating opentaps with, eBay, and Froogle.
  • Voice Over IP integration into opentaps CRM.
  • New opentaps Ajax UI framework tools have been developed and will now allow us to re-design much of the legacy static screens and forms.
  • New warehouse management applications for managing inventory, shipping (including UPS/DHL/FedEx integration), manufacturing.
  • New purchasing application for managing suppliers, purchase orders, and automating the procurement process.
  • Support for lot-level inventory management for food and beverage, pharmaceutical, and chemical industries.
  • New sales order entry systems in the CRM module, with enhanced support for bulk mailings and customer address validation.
  • Support for payroll, commissions, third party billing, and contract-based billing.
  • New library of tools for building online stores for opentaps with other languages and frameworks, developed in conjunction with the open source Joomla! content management project.
  • Last but not least, we have created a new opentaps documentation site which will be professionally developed and freely available to all opentaps users.
Coming Soon

Our immediate goals are to consolidate the significant progress of the past few months and lay the foundations for significantly greater growth in the future. As opentaps the application continues grow, it becomes imperative that we maintain consistency and quality. Meanwhile, as the opentaps community grows, we need to help new and existing users better understand how to leverage the full potential of opentaps.

Therefore, some of our most important investments right now are improving our documentation and unit testing. We are in the process of updating and re-writing many of the manuals for opentaps 0.9 on our new documentation site and plan to make it directly linkable from the opentaps, so all opentaps users could give live help from their screen. We are also in the process of implementing unit tests for some key application components.

Once we have made sufficient progress on these fronts, we will be ready to make the official opentaps 1.0 release.

Looking Ahead

Our fundamental goal remains the same: to make opentaps the enterprise application of choice for as many companies as possible.

Today opentaps is an open source ERP and CRM application with a strong out of the box feature set for product-based e-tailers, retailers, manufacturers, and distributors. We will continue to expand our offerings for these industries, but we also plan on broadening the feature set of opentaps to services companies. Some of the specific features planned are:
  • Fixed asset accounting
  • Improved manufacturing support, including enhanced Material Resources Planning and support for non-discrete manufacturing processes.
  • Support for services companies, including process/task and standard contract billing.
  • Improved marketing automation tools and supporting analytics
Simultaneously, we want to make opentaps technically more accessible, so that users could build extensions in a variety of languages and frameworks, be it Java, PHP, or Ruby On Rails. Finally, we plan to continue to improve our usability and documentation, so that it becomes increasingly easier for companies to implement and support opentaps.

Thank you again for using opentaps and being a part of our community!

Bookmark and Share