rsyslog

Rsyslog is a real open source project and open to contributions. By contributing, you help improve the state of logging as well as improve your own professional profile. Contributing is easy, and there are options for everyone – you don’t need to be developer.

These are many ways to contribute to the project:

• become a rsyslog ambassador and let other people know about rsyslog and how to utilize it for best results. Help rsyslog getting backlinks, be present on Internet news sites or at meetings you attend.
• help others by offering support on
  • the rsyslog forums
  • the rsyslog mailing list
• help with the documentation; you can either contribute
  • to the rsyslog doc inside the project git
  • to the rsyslog project web site — just ask us for account creation
  • on the rsyslog wiki
• become a bug-hunter and help with testing rsyslog development releases
• help driving the rsyslog infrastructure with its web sites, wiki’s and the like
• help creating packages
• or, obviously, help with rsyslog code development

This list is not conclusive. There for sure are many more ways to contribute and if you find one, just let us know. We are very open to new suggestions and like to try out new things.

We have also some more in-depth information on specific contribution topics available and more is upcoming. Right now, dig down into

• Contribution Policy

Again, your contribution is highly appreciated, and very rewarding. Participate in the open source movement!

Rsyslog is very open to contributions and they are highly appreciated. Basically, we accept any contribution that can potentially be of use for the rsyslog community. Documentation and code contributions are especially welcome. A successful contribution should

• come under the Apache Software License (ASL) 2.0; much of rsyslog’s code already has been converted to this license, but not everything yet. So please make sure you feel OK with ASL 2.0. We generally do not like GPL contributions any longer, as this causes trouble with the long-term goal of changing to ASL.
• provide a bugfix or feature that is -at least potentially- of general interest. If it’s really just for you and so specific that nobody else will ever want it, chances are a bit lower we’ll merge (except, of course, if it is an interesting PoC).
• a bit of documentation for new features or modules would be immensely useful. While we usually merge even without that, this actually means nobody will ever know about that particular new feature (we are way behind with doing our own doc, don’t expect us to document any other work ;)).
• do not break upward compatibility; if you really need to, discuss this on the rsyslog mailing list first
• do not unnecessarily duplicate a module; while we tend to accept such contributions, the process can take much longer as we will try to merge the functionality into the alread existing module
• if you contribute a new module with some non-standard tools, do not expect that we actually try the module out. We’ll usually merge it, but will flag it as non-project-supported and name the original author as contact points. Omoracle is one example. Don’t be put off contributing such a module — they can be immensly useful to the community, we just can’t work on all of them. If things become popular, we may involve ourselfs into it (ommongodb is an example for that).
• doc contributions should not be primarily promotional for some third party. If you contribute something you have originally written for another party, it’s usualy fine to include a “orignaly appeared on” backlink, but that should be sufficient.

As usual, these are just some general rules, and most of them common knowledge in any case. In simple words it’s very hard to find a reason NOT to merge a serious contribtion.