Who we are
The Hudson dev team can be thought of as consisting of two logical layers. One is the team that works on the core Hudson project, and the other is the folks who work on its plugins.
How we work
The group that works on the core doesn't have a strong organizational hierarchy. Technical decisions are made through discussions, releases are posted when they feel ready (which is normally once every 1-7 days), in rare occasions where things are disputed, Kohsuke often gets the final word.
On the other hand, people who work on plugins get free reign on their respective plugins. They maintain independent release schedules, and they don't normally discuss changes with people working on other plugins or the core team.
There's also a group of people who are helping with localization of Hudson. Localization is a cross-cutting concern, and as such they should feel free to work on the core Hudson as well as plugins.
The Hudson project encourages co-operation among people and expects developers to be very open to new contributors.
How to join
Unlike some of the other prominent open-source projects, such as most Apache projects, where the bar of entry to the project is very high, the Hudson project sets this bar very low.
Anyone is welcome to start new plugins and own them on Hudson project. While developing plugins outside the Hudson project is possible, doing so in the Hudson project enables us to better communicate with plugin authors, better advertise plugins, and provide future plugin developers with sample code to look into. If you are interested in hosting your plugin here, please drop us a note at users@hudson.dev.java.net.
Joining the core development is also very easy. While commit access is granted to almost right away, we ask new contributors to start with smaller changes, and discuss them before they make them. This process is necessary for a new contributor and the existing dev team to get familiar with each other.
Plugin projects are owned and run by their respective initiator, and so ultimately it is up to the plugin owner to decide how they take new contributions. That said, the expectation is that the process should be similar to that of the core.
Roadmap
Hudson doesn't really have a fixed roadmap. The development is mostly driven by the issue tracker, and developers each "scratch their own itch", so to speak.
There are, however, a few guiding principles in deciding what we do and what we don't:
- Ease of use is important. Things should "just work." We like fewer configuration options, and we like more automatic detection. So a new feature that adds configuration options is generally avoided. This is particularly true in the core and key plugins.
- Extensibility is encouraged, so that we can have many specialized plugins instead of fewer, generic plugins that require a lot of configuration.