As I'm sure most of you know, this weekend is Openbravo's 1st Annual Get Together. We just finished the morning session, and Rok Lenardic and I went for lunch. There, we wound up talking about the opening presentation of Matt Asay, the VP Business Development at Alfresco.

Now with any presentation, the 5 points you want your audience to remember do not always match up with the 5 points that they do remember. That is our disclaimer (partially for Matt), because Rok and I wound up talking about two specific things Matt said.

1. The upside down triangle: The traditional software model is the right side up triangle such that you develop a product, close it, and then hope you can get customers, making money in the process. This differs from open source model that resembles the upside down triangle. Develop a product, get people to use it and let the community guide you towards a better solution. As Matt put it: "What we want first is a lot of users, then monetize on the services." The result is a product that people want (Rok's favourite quote from Paul Graham).

2. A subtle value of open source for the customer: Matt mentioned that from a customer point of view, the risk level is lower. Wheras with proprietary software, users bear 100% of the risk because they purchase a closed product and get locked in with the vendor. With open source the risk is shared. The solution is open meaning that the product becomes bigger than the company as the code and infrastructure is more open. If the company does a bad job, a fork will occur, the product will survive with its community. If the company does well, the community will grow and stick together in support. Additional functionality will result as will the higher quality of the product.

Rok and I are truly enjoying the weekend. Partners are seeing an extremely high level of transparency from our executive, getting questions answered about the product, and seeing the direction of the company. Yes, what is left of the once "rumor" is true, we are becoming "a real badass company with supa plans for the fucha' :-)"

One final note: 15,000 known installations for Alfresco, hopefully Openbravo will be there soon.

There is no doubt that Openbravo's community is growing very fast. The strength of the product -which has been in production since 2001-, and a truly open company vision, which places the community at the core of everything we do (from development and testing to documentation) is no doubt helping.

Born on April 19th, 2006 (the date when Openbravo's code was first was published in SourceForge) the following indicators clearly show Openbravo's community has enjoyed a remarkable activity:

• More than 350,000 accumulated downloads (today we have more than 1,000 average downloads a day)
• 1,400 bugs reported
• 41 registered localization projects
• 7,500 messages in 11 forums, with
• 172 individuals participating every month (17 are Openbravo employees)
• 67 registered developers in SourceForge.net (31 are Openbravo employees)
• 933 registered in the wiki (30 are Openbravo employees)

Right now I am getting the final confirmed attendants in our first international community gathering in Barcelona: the so called Openbravo Get Together and they look great! We have confirmed the attendance of almost 200 participants coming from 31 different countries representing all continents.

We will cover several topics, including business and technical aspects. We also will show case one of the first tangible results of the Open Solutions Alliance: the Common Customer View project's single sign-on.

For all of you attending ... THANK YOU and a WARM WELCOME TO BARCELONA! I don't have any doubts that you will enjoy the event and will help bring Openbravo's community one step forward.

For those that you can not attend, don't be sad: we will post the different presentations and summaries of the different sessions.

This is only the beginning!

One of the most frequent requests that we get from our community is an opportunity to participate in the Openbravo quality assurance process.

Well... here it is.

Starting with the upcoming 2.35 Acceptance Testing, we would like to take a small step in that direction and ask for a handful of volunteers to test some of the mechanics. If you are willing and able, you can notify us by sending an email to collaborate@openbravo.com.

Here is what we are asking:

1. When Openbravo 2.35 code is frozen, we will give you early access to the installer through a private FTP server. You will essentially receive the release at the same time as our QA team.
2. We will give you access to our QA portal, where you can see our test cases for the acceptance test.
3. We will assign you a set of test cases and we expect that you will install the application on your server, run the test cases and report the outcome in the QA portal
   
4. We will also assign you a set of bugs to verify (i.e. validate that bugs that are supposed to be fixed in 2.35 are indeed fixed)
5. We will also welcome any other testing that you might be inclined to perform, including verifying bug fixes that are critical to you or your customers.
6. If you have any questions or doubts during the process, we will be available on the IRC channel to answer.
   

The whole thing should start early next week (October 22nd) and take 2 or 3 days of your time, if everything goes well (does it ever?).

Please remember that this is going to be Acceptance Testing, not a full blown QA cycle. The purpose of Acceptance Testing is to validate that an already QA'ed release is good to go and that the last build didn't introduce any major regression (essentially: test the product as it is going to be shipped before your users do to avoid to be embarrassed later).
Because of that, we will stop the release only if one of the test cases fails with a significant bug or one of the critical bugs that we thought had been fixed still reproduces. Nonetheless, we do expect you to log all issues you find, including small bugs, as we will fix those in future releases.

What's in it for you? Well... practically not much, but you can be very proud to have helped the community and to have contributed to speed up the release of the best version ever of Openbravo. You will also be able to validate that bug fixes critical to you and your customers are indeed fixed.
Finally, you will also get a mention in our release notes, so there is some glory at stake.

So... why such a small step now? And why accepting only a handful of volunteers rather than the whole community?
Well... this is a factor of where we are in the release. Openbravo 2.3x went already through several rounds of full blown QA testing and 4 public releases (2.30, 2.31, 2.33 and 2.34). So Acceptance Testing is what we need to do next and, since the scope is quite limited, it would not make sense to involve too many people. Also, this is the first time we do this, and we would like to make sure that we can coordinate with a few people before we try with many in order to avoid wasting people's time.

For the next major release, Openbravo 2.4x, we have more ambitious plans which will include a public participation of the whole community, public status reporting, etc. We will be working on the definition of that process over the next few weeks. One of the key outstanding issues is being able to publish frequent releases to the community in order to get frequent feedback on fresh code: at the moment the build process is time consuming and manual intensive but we are working to address that.

If you have good ideas, feel free to post them as comments.

Today it is exactly two months since I joined Openbravo and I thought that the best way to celebrate is to write my first blog entry.
What will I write about? Well.. Openbravo obviously, but also other topics that might be of interest to the Openbravo community.
And what better way to start than to cover a topic that has been very hot with our community in the recent weeks... release management and release maturity.

When Openbravo 2.30 was released, the project published it as an alpha release but that status was declared only in the news announcement. When we published 2.31, we published it as beta using the same announcement mechanism.
The success of these releases was so overwhelming that, when we eventually announced 2.33, we were not clear enough on whether it was suitable for production purposes or not.

As it turned out, that was a major mistake and that lack of clarity created a lot of confusion among our community. We tried to correct it with 2.34 which was published as beta, but at that point it was too late. The damage had been done.

Through this experience, we learned our lesson and we have now published an updated release policy. All the details are in that document but, in a nutshell, we intend to distinguish between Community Edition, which is intended to be stable and well tested but published twice a year, and Developer's Edition, which is intended to be published very frequently and includes all the latest development, including features in progress.

The Community Edition will go through a stabilization process, moving from alpha version, to one or more beta versions, and eventually to production. At all stages, the status of the release will be very clearly marked both in its name and in the release notes and - by default - users will not be directed to download the alpha or beta releases but the previous stable production release.

It is too late to apply this policy for 2.3x but we will start following it with 2.4x and use it for all future releases. We hope that this policy will greatly help our community by setting the right expectations on production usage and avoid some of the confusions and frustrations that users experienced in the past.

At the same time, the Developer's Edition will allow the community to be involved in our development process and to give us early feedback on the features we are working on. This will give us not only an opportunity to continuously fine tune our product based on your input, but also to reduce the stabilization cycle of the Community Edition.

After long delays, SAP has finally presented a new additional product targeting SMEs. For a long time the product, code named A1S, now comes to life with a new brand name: SAP Business Bydesign. Although many things are still unclear (how much is slideware vs. real product with optimal performance, what will be the future of SAP Business One, what will be the role of SAP midmarket channel partners, will SAP achieve its aggressive targets,…) this movement is a recognition that the industry is changing and web-based technologies are the future, as we saw many years ago from our foundation back in 2001. Additionally, we believe that SaaS makes a lot of sense for many SME clients which are not IT experts and look for an affordable, easy to configure solution without IT hassles. And therefore SaaS is here to stay and I am sure SAP will be a great contributor/ enabler in growing up this market.

At the end, I believe SAP will help us grow the market and since SAP remains closed source (big surprise ;-) and I still think the new leaders of tomorrow will be companies who adopt a new and better way to develop and sell software the open source way …Openbravo is also here to stay!