Openbravo announces commercial relationship with Canonical + native Ubuntu package

In case you haven’t seen the press release (Openbravo broadens support for Ubuntu with commercial open source ERP package), Openbravo now provides a fully-supported, subscription-based ERP offering on Ubuntu’s technology stack, with an easy-to-install native Ubuntu package. The pre-integrated and supported technology stack features Ubuntu 9.04, PostgreSQL 8.3, and Tomcat 6. If you want to skip the press release and head straight to the goodies, this link will tell you how.

So now what’s your excuse for not implementing Openbravo ERP? ☺

Openbravo Forge: Real-world Collaborative Development Examples

Since joining Openbravo in April, I have spent time speaking with members of our ecosystem and personally experiencing the Openbravo Forge. As expected, members of the ecosystem can now complete projects in collaboration with or independently from Openbravo staff. However, I am surprised by the results we have been able to achieve so quickly, and am really please to see how some business practices have dramatically improved.

Re: the quantitative numbers, as of this writing the Openbravo Forge statistics (publicly shown in the upper right corner of the screen) read “139 projects and 6997 developers”!

Read on for some qualitative examples of what is happening at the Openbravo Forge.

Partner and Ecosystem Contributions and the Resulting Exposure

The old way: Openbravo Partners and the ecosystem completed extensions and had difficulty sharing them worldwide.

The new way: Openbravo Partners and the ecosystem are collectively sharing extensions, gaining wide exposure in the process.

Success Stories: Since the Forge went live, companies like Opensistemas have started publishing some of their extensions there. During an implementation for well-recognized European Fast Food Chain Bocatta, Opensistemas implemented POS features such as a kitchen monitor, an expanded menu, and an ingredients menu. For those in the ecosystem, these features are available here.

Community Translation and Localization Projects

The old way: Openbravo staff created an SVN branch so translators and the community could support these efforts. Openbravo staff was required to personally create localization packages and release them on our specific release schedule.

The new way: The Openbravo Forge lets anyone create their own translation project and release it as desired. They do not require any daily support from Openbravo.

Success Stories: Since the Forge went live, Openbravo staff has been able to invest more time supporting ecosystem efforts and less time on basic administration. As a result, country location projects are growing daily:

• Estonian Translation
• German Translation
• Russian Translation
• Arabic Translation
• and much more...

Independently Learning about and Creating Openbravo Modules

The old way: The ecosystem learned how to develop on top of Openbravo via wiki documentation.

The new way: The forge makes it more attractive to learn how to develop modules via interactive collaboration with Openbravo.

Success Stories: Right now in Pakistan, a Computer Science Professor is using the Forge to mentor development projects for his students. With the forge, his students have all the tools they need to learn about a development process in open source. The result for the ecosystem is a set of new and exciting features. The result of Openbravo is the opportunity to mentor the teacher and the students on how to develop for Openbravo. You can check their progress here and here.

Partners and the Ecosystem Create and Manage Projects in Private on the Forge…for Free

The old way: Some partners and ecosystem members were required to pay for a private Forge space, manage their projects on a public Forge, or potentially use a rudimentary sharing tool in order to control project management.

The new way: Partners can manage their projects privately on the Openbravo Forge. Neither Openbravo nor the community will have any access to private project content. Free hosted project services include forums, news, downloads, bug tracking, versioning control system for code, and Wiki / Central Repository modules integration.

Success Stories: As of today, Openbravo is only aware of the 115 public projects on the Forge. Unless a staff member is provided access by a project administrator, we are unable to view any work being completed in a private Forge project.

The Forge is actively helping the ecosystem quickly bring Openbravo ERP to new markets and industries. This is because members of the ecosystem can independently connect with one another. They can also have the flexibility to choose what projects to work on, or even to start a project publicly or privately. As for Openbravo, we spend much less time on administration and basic coordination, and much more time on guidance and support.

Virtual and Face-to-Face Collaboration

One final thought on Openbravo’s growing ecosystem and our efforts to support it. While the Openbravo Forge is a great tool to support asynchronous collaboration, we at Openbravo also strongly believe in the traditional face-to-face method, and our biggest event is the Openbravo World Conference (OBWC). For a glimpse of what the 2009 edition offered, please see this video. Happy collaborating via the forge, and I hope to see you at OBWC 2010!

Openbravo 3rd Party Integrations and the Modularity Concept: Empowering End Customers

Attracting 3rd party ISVs is a critical element of Openbravo ERP's value proposition to it's end customers. As of version 2.50, released this spring, ISVs (and VARs, System Integrators, etc.) can now efficiently add features, functionality, and integrations to extend Openbravo's core capabilities, via the modularity subsystem.

I am amazed at how quickly Openbravo's ecosystem has responded to this new capability, with dozens of Openbravo-related Integration and Modularity projects already underway on the Openbravo Forge. I'd like to take a minute to highlight a few of them:

1. Elondra Mobile Sales Order Management: Openbravo ERP is now integrated with Elondra's bmSales. Customers are able to log sales orders in their mobile device using bmSales, and later transfer those sales to Openbravo ERP. They can also load information required to create orders directly into the mobile device.
2. ProcessMaker Workflow Management: Via web services, Openbravo ERP is now integrated with ProcessMaker BPM, adding additional workflow capabilities to the solution. Any information added to ProcessMaker is automatically shared with Openbravo to generate Expense Sheets, Purchase Invoices, and Sales Orders in Openbravo ERP. Forms and reports can be routed to the correct business partner for approval. The entire process may be tracked by a supervisor.
3. Funambol Data Synchronization: This recently-launched project will synchronize Openbravo ERP data using Funambol synchronization server. Once completed, users will be able to take commonly used data from laptops, iphones, Mozilla Thunderbird / Microsoft Outlook, Gmail, Google calendar, etc, and synchronize everything to the ERP for easy access and use.

Access to a growing list of 3rd party modules is a huge benefit for Openbravo customers, extending the range of available functionality and introducing them to valuable complementary products and companies . Openbravo ERP is quickly growing up--from a fully-functional, standalone business management system to a robust platform, wide-open for business!

The Business Side of Modularity: Food for Thought

Since I joined Openbravo in April, I’ve been hearing a lot about “modularity” and what a significant enabler it is for the ecosystem. Paolo Juvara wrote an incredible blog post on this topic, detailing the technology and explaining the theoretical ecosystem dynamics that it supports. There is a lot of information in that post, and it raised a number of “food for thought” business questions for me that I’d like to get feedback on.

Before raising those questions, here is my shorthand on modularity’s “Big Idea”:

• Reusability + Autonomy + Exposure = Scalability (of the Ecosystem)

Let me explain. As a participant in a software development ecosystem (or you can use the word “community” if you like), I have 3 major business-oriented goals:

• Reusability: Let me leverage the work of others
• Autonomy: Let me create what I want and contribute it (so others can leverage)
• Exposure: Provide me a means of public recognition (so I can monetize my contributions in some ways)

When a software ecosystem is structured to effectively and efficiently meet these 3 business goals, then it is designed to be scalable, with no internal factors gating growth. Openbravo Modularity certainly provides for reusability, allowing formal packaging at 3 levels of granularity (module, pack, template). And its formal dependency support enables reuse across versions and different authors. Autonomy is also provided, as well as exposure (through publishing modules via the online Central Repository).

So all of the basic requirements are met. What’s not to like? J But of course the key business challenge with all new platforms and ecosystems is that their growth is governed by the “Network Effect”, in which large benefits to the participants don’t accrue until a “critical mass” is reached (in this case, a critical mass of software authors and users). So, until there are large numbers of consumers, it is difficult to attract large numbers of producers. Conversely, small numbers of producers discourage new consumers from joining.

The platform must deliver enough tangible value to attract increasing numbers of both producers and consumers over time. We at Openbravo are adding that tangible, practical value to our ERP platform on a continuous basis, and Modularity is a part of that. We are very excited to see where the ecosystem takes this!

With that backdrop, it’s time for my “food for thought” questions related to Openbravo Modularity.

Both commercial modules (pay first, then download) and community modules (free as in both beer and speech) will be supported in Openbravo's integrated Central Repository. Which will dominate? Stated another way, will most module authors act as ISVs (creating software that they enhance and maintain over time), or will most freely contribute their work to gain recognition for the purpose of selling custom services (effectively using their software as an advertisement)? Will the pattern change over time (as the number of consumers grows)? Will authors who started as custom services developers gain domain expertise in an area and evolve into an ISV focused on that vertical? Will authors start out charging for their modules, and then turn them over to the community after a certain period of time (when they have recouped their development cost via the sales)?

What about module size and granularity—will we see large numbers of small “drive-by contributions” (single reports, small integration to a 3^rd-party system, purpose-built inquiry screen, etc.), or a smaller number of complete industry templates? How will that pattern change as the ecosystem grows? Will end customers contribute modules, or only partners?

What will the partner channel look like over time? Will most partners continue to Develop, Sell, and Implement, or will we see increasing specialization over time (perhaps with most custom Development clustering in countries with favorable labor rates and quality developers?). Will some organizations focus on selling, subcontracting the implementation work to others? Will partners collaborate extensively, with partners on one side of the globe localizing modules created by others on the other side? (the Openbravo Forge will certainly enable that!)

Will “first move advantage” dominate, i.e. will being the first module for a certain area generally mean you will be number 1 two years from now? Will the presence of an existing module discourage other authors from competing, or will we see a lot of competition in high-volume niches?

What are the biggest challenges to Openbravo's 3rd-party ecosystem reaching critical mass? What can we do better?

Please feel free to provide public feedback / speculation here.

Hidden Architecture Syndrome: Definition & Longterm Effects

Software architecture as archeological dig (when engineers have no voice)

A common criticism of Open Source software vendors (most often made by our proprietary brethren) is that Open Source vendors are founded by engineers and technologists who do not understand commercial business, and the importance of the sales and marketing functions. I will let that generalization stand for now (of course, commercial success requires a proper balance across the disciplines!), and focus my first series of posts on the "flip side", namely:

• what generally happens over time in "sales-driven" software companies?

Note: My comments are focused on the mid-market ERP space, with which I am very familiar.

Context

First, some context. As a relative newbie to the world of Open Source ERP, I was immediately struck by how transparent and "out in the open" everything is, at least here at Openbravo--not just the source code, but complete documentation, release status, virtually everything! My iGoogle now has a graphical widget that shows me the number of open bugs in the new Openbravo 2.50 release, by severity. Take a look at Openbravo's public wiki: as a new employee, I can be told "just read the wiki, and you will be pretty much up to speed re: what we are up to". Wow, all there on the web, linked together, searchable, easy to consume (even from an iPhone!) .

And once you start reading, you see topics like "Concepts for Openbravo ERP Redesign". Yowza, "Redesign"?, why do we need a redesign? That makes it sound like what we have now is no good. Did I take the right job? And then you step back and realize that in the proprietary world, you were used to spending a lot of cycles on perception (so time is spent by high-priced marketing staff "sanitizing" such politically incorrect verbiage). Here in opensource land, we are doing real Collaborative User Experience Design (complete with UI mockups) out in the open with partners and clients!

And as I am reading and learning more, it occurs to me that this transparency is not just a "difference", it is a hugely valuable differentiator. The first area I want to talk about related to transparency is Software Architecture, which in my experience is a mission-critical Software Engineering discipline that requires ongoing investment to deliver sustainable, adaptable business systems that will last over the course of decades. Open Source vendors tend to be very strong in this area, simply because the Darwinian nature of the overall open source ecosystem demands it--architectural weaknesses are quickly exposed publicly, and, if not addressed, your open source project will die due to lack of interest on the part of developers. So, the transparency assures that only the best architectures will actually be built upon, and that they will be updated with worthy new technologies that inevitably arise in the future (recent past examples include RESTful Web Services and AJAX).

So what happens over time when a system's architecture is allowed to evolve in a non-transparent, "hidden" manner, as is often the case with sales-driven, proprietary mid-market ERP vendors?

Hidden Architecture Syndrome

Well, the short answer is that "Hidden Architecture Syndrome" (HAS) sets in. And, depending on where the proprietary product is in its lifecycle, the symptoms of this syndrome do not bode well for its users, longterm.

I have identified 5 phases of HAS, based on my experiences working in the mid-market ERP space:

1. Life is Good: We have a product that fits a niche!
2. Bulk Up: Our success has attracted competition
3. Attrition & Contraction: Initial effects of technological obsolescence
4. Pump up the Marketing: This stuff is still good, just need more focused marketing for new deals
5. Keep Milking the Base / Get Acquired: (aka, "Decision time for customers")

One final thought at this point: Why is the "common wisdom", as espoused by the analyst firms (Gartner, AMR, etc.), that the shelf life (or customer buying cycle) for an ERP system is 7-10 years? I think that much of the answer is that Hidden Architecture Syndrome is prevalent industry-wide, and a decade is about how long a vendor can profitably "ride" any given architecture (before dramatically reducing the R&D investment on that "legacy" system).

But it doesn't have to be that way, does it? What if your ERP vendor actually invested in a rock solid, modern architecture, and then invested incrementally to refine and improve it at every release? From an economic perspective, nobody actually wants to "rip and replace" every decade (conceptually, that's like planning to get a divorce once per decade). Doesn't it make a lot more sense to find that perfect partner, one who shares your goals and openly commits to making the necessary investments? Think that perfect partner doesn't exist? Think you can't have "ERP for Life"? Perhaps you haven't been looking in the right places! :)

Introduction

I'm John Fandl and I have a confession to make: my 20+ year career has centered around working with proprietary software companies (Supply Chain, ERP, and ERP-centric BI/Analytics). That is, until recently, when I moved over to open source ERP supplier Openbravo.

Actually I'm still in process with this move, which will take me and my family from Naperville, IL (U.S.) to Barcelona, Spain this spring. So, I likely won't find much time for many posts until I'm settled in the job, and the family is settled in Spain. Not to mention going thru that "Proprietary Anonymous 12-Step Program"! :)

When I do post to this blog, it will be about ERP-related topics, with my own slant on the differences between proprietary vs. open source ERP. I'm already seeing major differences related to "developing in a fishbowl", and I will post on how the lack of transparency in proprietary software companies results in "Hidden Architecture Syndrome", and how that impacts customers.

I call things as I see them, so don't expect me to beat up on proprietary competition as a general rule. Hey, that's where I came from, and all of the real professionals I have had the privilege of working with care deeply about their customers, co-workers, and the software they produce. And that's one thing that won't change for me!