The Principles behind Open Source

There are lots of definitions of open source. Most of them focus on the pragmatic consequences associated with open source. I would like to share with you the principles I believe lie behind open source.

People
People is the most important asset in open source. It is even more important than code. Code is just a response to the needs of people. The core of open source projects is communication between people: discussions in irc, issue reporting in bug tracker, support through forums, polls… The ‘release early, release often’ policy is a way of getting users feedback as soon as possible. Users are important. Developers are important. Everything rotates around people.

Values
Open source projects share a common set of values. These values have evolved into some tools and processes. Having a clear set of values makes taking decisions easier, leads you through a coherent path and allows the rest of the people know what to expect from you. The more loyal you are to your values, the smoother the path is. The difficult part could be choosing the right values, but that is already done in open source. You can find some of those values in the Openbravo Manifesto. You can search in google for more values (e.g., consensus, distributed model, legitimacy).

Abundance
Probably the main trait of open source is the abundance mentality of the people participating. The opposite of abundance mentality is scarcity mentality. People with scarcity mentality think that they are what they do and know; that if they give away what they do and share their knowledge, they are losing value. Scarcity mentality sees everything as a zero sum game. On the other hand, people with abundance mentality think they are what they can do; therefore, if they give away what they do, they are not losing value. The more value they create and deliver, the better. Abundance mentality means betting on your capacity of creating and delivering more value.

These principles are not unique to open source. Open source is just one possible implementation of these principles, but any business or project (open or not) could take advantage of these principles. You could use these principles to analyze your own business/project. Are you giving enough importance to all people involved in your project? Do you have a clear set of values that is shared by everyone in the project? Are you measuring your project by the capacity of creating and delivering value?

SCM migration: from subversion to mercurial

As some of you already know, we are planning to migrate our SCM from Subversion to Mercurial. We would like to share with you the work we have already done and ask you for your collaboration and feedback.

We have created a document in the wiki that explains what have we done and what the future steps are. The first thing we would like to ask you is to read that document and give us feedback.

In that document, there is a section that explains some of the processes that will be in place when we use Mercurial. The second thing we would like to ask you is to test these processes. Are they correct? Are we missing something?

If you want to help us testing, send an email to staff.rm@openbravo.com. We will provide you all information needed to start testing (including credentials to access some test repositories). The processes described in the document are a recommendation, but you can test whatever you want. If you think of any other process or of a different way of doing things, feel free to explore them and give us your feedback.

Thanks in advance.

Development Environment ID in Openbravo ERP developments

The Development Environment ID was created to allow merging dictionary changes made by several developers simultaneously. Previously, the Development Environment ID list was centrally maintained by Openbravo.

With the inclusion of UUID in version 2.50, the Development Environment ID is not needed any more. Because of this, Openbravo is no longer going to maintain this list of Development Environment IDs.

However, if you are working on a development of Openbravo ERP in a version prior to 2.50 with several developers, you still need the Developer Environment ID. In this case, you can manage the Development Environment IDs of your project taking into account two things:

• Development Environment IDs should be five digit numbers starting by ‘1’ (e.g.: 10001, 10002, 10003).

• Assign a different Developer Environment ID to each of the developers in a project. Note that the same ID could be used through different projects.

Please, do not hesitate to visit the developers forum if you have any question or suggestion regarding Openbravo ERP development.

Mantis goes live!

We started using Sourceforge two years ago, and since then we have done an intense use of it. Sourceforge is a great place to start a project because it gives you all the community tools you need in one place. But when projects grow, initial requisites may change and Sourceforge may not have all the flexibility needed.

As you may already know, we have been working in changing our issue tracker from SourceForge to Mantis. The transition is now complete and we now use Mantis as our only tracker. From now on, please report issues at issues.openbravo.com.

The main advantages of Mantis are that it provides a lot of flexibility, it has multiple projects, advanced filtering, subversion integration, advanced access level management, customizable issue workflow, issue relationships… Additionally it’s open source and that ensures us we can change it in the future.

All bugs have been migrated from Sourceforge to Mantis. From now on, you should only work with Mantis. New bugs should be reported there and old bugs can also be found there. When reporting a bug, remember to follow our guidelines.

If you have any comments about our implementation of Mantis, please feel free to tell us so. You can post general ideas as comments to this post or you can report defects and feature requests at issues.openbravo.com in the project Mantis@OB.

Mantis, the new Openbravo bug tracking system enters into the beta process

If you have been participating on the Openbravo ERP or POS Acceptance Test you have noticed that we have started to use the Mantis issue tracker system at Openbravo. Mantis provides many benefits over SourceForge Tracker, the system that we have been traditionally using. Among them: better reporting, advanced query features, custom fields, tags and many others; all of this, coupled with a better system performance and an open source license.

We are still in the testing phase for the new issue tracker and we are tacking advantage of the ERP 2.40 alpha cycle to, at the same time, test our Mantis deployment. During a period of time of approximately two weeks, we will be using simultaneously Mantis -for issues on the 2.40 alpha release- and Source Forget Tracker -for issues on the production releases. After that period, Mantis will be fully in production and it would be the only system.

You can access the new tracker at issues.openbravo.com. We invite you to test it at any time. If you are testing 2.40 alpha, we would also prefer if you logged issues there while if you are using any other release, we would ask you to continue use SourceForge (but do not worry, we will attend to your request no matter where you log them). If you have any feedback, you can post it in the Openbravo Open Discussion forum. You can also log defects and feature requests on our Mantis implementation directly in Mantis by logging an issue in the Mantis@OB project.

When Mantis enters finally into production, we will blog about it and we will update the bug guidelines and other documents in the wiki.