No. We expect that most people will simply want to use the system as it is (or rather, as it is after they have configured it to meet their specific needs), without changing the core system itself or adding any new packages. Such users are under no obligation to contribute.

The bazaar of course. eCos is developed using an open development model. In addition to the full releases anonymous CVS access to the current development sources is provided. Discussions about the system will generally be held in the open ecos-discuss mailing list. However it is necessary to apply a caveat to this: some developers prefer to keep their commercial work confidential, for example due to non-disclosure agreements. It is only when that port is distributed that all the eCos code must be made available under the terms of the GPL.

There are ways of contributing to eCos development which involve very little effort. Providing constructive comments on any part of the system, including the documentation and the web site, helps us to identify areas which need improvement. Reporting a problem gives us a chance to fix it, especially if you provide us with a simple test case and sufficient information to reproduce the problem. Participation in the discussions in the ecos-discuss mailing list gives us a better understanding of the user community, and perhaps some new ideas.

If you wish to contribute to the actual code there are multiple levels of involvement. You can write a new package. This could be a HAL package as part of a port of the system to new hardware. It could be a device driver. It could provide some new functionality such as a graphics library. It could be a port of some existing software that is appropriate for embedded systems. You can enhance an existing package, for example the eCos kernel. If you find a bug in the system then you can provide a patch that fixes it. You may also find a way to rewrite some existing code so that it becomes more efficient and/or needs less memory. You may add new functionality. Contributions to the documentation and to the test suites are particularly welcome, since these areas are often overlooked by contributors.

All patches should be sent to the ecos-patches mailing list which is explicitly for this purpose. Discussion of the patch may take place there, and indeed an eCos maintainer may advise you of any mistakes in the patch, or any other reason why the patch may not be included in eCos. For non-trivial patches to the core system we generally require a copyright assignment.

The most important criterion is that the contribution must enhance the system. If it meets this fundamental criterion then there is a good chance that the contribution will be accepted. More specific criteria include the following:

1. It must not have undesirable effects in terms of code size, data size, CPU cycles, or determinism of the system. This restriction can be relaxed if the new behavior can only be explicitly enabled by means of one or more configuration options.

2. It must be portable to all affected platforms. Usually this means that for anything except a new HAL package the code must be fully portable.

3. It should adhere to the project's coding standards. Most importantly the new code should contain appropriate assertions and comments.

4. Where appropriate (which is nearly always) it should be accompanied by appropriate test cases and documentation.

5. There must not be any confusion about licensing or ownership. This may require a copyright assignment.

A contribution need not meet all these requirements immediately. In fact it often makes sense to start with a proposal on the an appropriate mailing list, possibly including an initial patch which is known to be unacceptable, with the understanding that the contributor will make further changes. If there are major problems with the proposed contribution then it is better to detect these early on. If there is existing code elsewhere which does much the same job then it is good to know about this as well, to avoid duplication of effort. There may be better and easier ways to tackle the problem.

If a contribution involves a significant change to part of the core system, for example the kernel, then usually we will need a copyright assignment before we can incorporate the changes into the system. The reason for this is to protect the community at large. In theory there is no need for copyright assignments because all changes to code covered by the eCos public license are also covered by that license. In practice copyright assignment provides a useful extra level of protection.

As an example, consider a scenario where a junior programmer makes a change to the system and releases it without the knowledge or consent of management. Some time later management finds out about the contribution, and decides that it should not have happened. The junior programmer gets severely reprimanded. The company's lawyers now approach various users of eCos, claiming that the contribution violated the company's copyright or quite possibly a patent, and demanding royalties. Until the issue gets resolved there would be a significant amount of fear, uncertainty, and doubt amongst the development community. This would be very harmful. The process of copyright assignment should prevent this and many other scenarios from ever arising, because it includes having a disclaimer signed by an officer of the company or a person with the necessary authority.

We are aware that copyright assignments involve an unpleasant amount of bureaucracy for many contributors, especially since we have to deal with the paperwork at the other end. However, we believe that the additional protection offered is necessary for the eCos user community as a whole.

Our contributions page indicates various projects that people are working on. In the future, these pages will be expanded to include projects that have been suggested but have not yet started. Typically additions to these projects will be proposed on the ecos-discuss mailing list, discussed for a while, and then a summary will be prepared.

At this time, the only developers allowed direct write access to the anonymous CVS repository are the eCos maintainers. A developer may be co-opted to become an eCos maintainer if he or she has been a valued contributor in the past.

However, at some future stage, once there are a sufficiently large number of external developers, some of these developers may well be given write access to the CVS server.

For contributed packages which are not in the core system, the intention is eventually to set up a separate area on the anonymous CVS server and give the relevant developers write access to just the relevant directories.