>…translated from Latin into English, “One for All, and All for One”. It’s a motto I think fits well for both open source development and for data standards development. It’s a concept that can be hard for a company to over come, especially internally amongst it’s sales force.
In recent weeks, I’ve seen a protectionism concept develope or become more apparent in both some open source projects, as well as with data standards. In the data standards world, this protectionism comes in the form of being afraid to benefit one’s competitors by adding data to the specification that doesn’t already exist. I’m not talking about the one off implementations, I’m talking about actually making the data requirements part of the specification. Some companies feel that this gives away a competitive edge, and that by standardizing the data they are helping their competitors. This depends on how one looks at it…are your data requirements so unique that they give you the competitive edge, or are you expressing the same requirements as the rest of the industry participants but in slightly different ways. Shouldn’t you be competting on value added features, instead of what data requirements are included or not included into a specificiation. I would argue that the value added features your customers want, aren’t necessarily dictated by which field is in the file or what it is called if it is there. It may help to implement the feature…but I bet somebody else has the same requirement, or it may already be there.
Like the issue with data standards, comes the issue with common functionality that most open source projects address. Instead of inventing the wheel multiple different ways, a common framework and tooling set can be developed. Yes, some people are saying that their competitors aren’t contributing to the project (or data standard) are gaining the benefits from their work, so why do it. By building a community, and bringing in the help that is needed, one can free up resources to work on the truelly value added items for your product. You may even find that you can convince that competitor that it’s in their interest as well as yours to work on a common framework. The portions of each of your products can then focus on what is truelly value added and truely set yourself apart. Most eclipse projects do a good job at this, others still need some prodding by the community in the right direction. Most organizations that deal with data standards are still learning this concept. Some industries adopt to this concept faster than others.
Whether the common framework is an IDE platform, RCP framework, or a data standard specification, the goal is the same. To stop re-inventing the wheel, to reduce overall development costs, and concentrate resources on areas that provide the true value added features to your customers. Oh and for those of you that are working on an open source project because you feel you aren’t benefiting a commercial application, think about the logic of that statement. It’s open source…anybody can use it.