Jenkins : Before starting a new plugin

Created by Unknown User (rseguy), last modified by Unknown User (drewbug) on Jul 20, 2015

One of Jenkins' main strengths is its plugins (and their openness). Over a thousand are already available, and brand new plugins become available every week or so. As such, there's quite likely one or more plugins which cover your needs.

In case some existing plugins partly cover your needs, we encourage you to contribute directly to these plugins rather than starting new ones from scratch. Profusion of plugins is good, profusion of plugins doing the same thing or so is not as good (smile)

What does this mean? Well, two things:

  1. That plugin maintainers should do their best to welcome contributions on their plugins (see below);
  2. That people with specific needs should try to work on existing plugins preferably to creating brand new ones, when applicable, of course (see below).

What if my idea seems unique?

Even if, having read the sections below, you believe that you have a unique need to write a plugin, consider the following:

  1. Search the plugin list here or inside Jenkins for something that could potentially be similar
  2. Search the list of plugin repositories for something possibly similar
  3. Search Google for people discussing similar ideas; perhaps there's a plugin not published in the update centre that someone could share
  4. Search the users' and developers' mailing list archives for similar ideas
  5. Talk to us! Many people start writing plugins, then ask us for hosting, only to find out that there was another plugin they had missed; or we may be able to recommend a good approach to use when writing your plugin.
    Get in touch via the jenkinsci-dev mailing list, or stop by IRC

Plugin maintainers: Welcome changes from contributors!

Maintainers, have you read the two following sections in Hosting Plugins?

These two sections are really important as they allow potential contributors to quickly have an access to your plugin's source code and documentation in order to contribute to it.

Apart from that, we also recommend applying the following best practices (if you see any other, please add them):

  • Document your code:
    Nothing special to say here, having documented code helps people contributing to it. Would you imagine writing a plugin without having Jenkins' javadoc? The same applies for your plugin (smile)
  • Clearly identify the license(s) which applies to your plugin:
    Licensing is really important when it comes to contributing code. As such, we encourage you to follow one or several of the following practices:
    (1) Add a license header at the top of each of your source code files;
    (2) Add a LICENSE file at the root of your Maven project;
    (3) Fill the <licenses> section of your POM.
    If nothing is defined, your code will be assumed to fall under the MIT license terms.
  • Welcome change:
    Well, nothing to say here also... Avoid the "NoDeByMe" (not developed by me) phobia. Jenkins would not be what it is today if it was reluctant to changes (smile)
  • Emphasize the fact that your plugin gets orphan:
    If you don't maintain your plugin anymore, emphasize it in the wiki. We're sure many people will be happy to take over for you.
  • Finally, answer e-mails:
    This principle actually goes along with welcoming changes. If somebody sends you a mail to contribute to your plugin, pay attention to it, and welcome it.

People with different needs: Work on existing plugins!

Before starting a brand new plugin, we encourage you to do the following:

  1. Search for existing plugins that cover your needs.
  2. If some plugins partly cover your needs:
    • Check if the licensing terms are compliant with what you expect (note: most of Jenkins' plugins are covered by the MIT license);
    • Take a look at the plugin's source code/documentation to see if you can, technically speaking, bring in the changes you need;
    • Contact the maintainer (both directly and through the Jenkins developer discussion list) to engage a discussion on how to contribute the changes you need. Some of the maintainers will just say "go ahead and bring in your changes", some will be happy to provide you with more help, some will even possibly code for you.
      If you don't get an answer from the maintainer after a few days, contact him/her/them again and be patient for a few more days as he/she/they might simply be away for some time.
      If you really don't get an answer (or a negative one), well, it might be time for you to start your own plugin.
  3. If you cannot find a plugin that looks similar to what you need, drop an email to the Jenkins developer list to see if:
    • There is a plugin, but it was not obvious that it could help you
    • Someone already has a "private" version of a plugin that they are using, that they may want to share now they know that someone else has a similar need
    • There are developers that want to help you write and/ or test your new plugin
  4. If no plugins cover your needs, well, go ahead and happy coding!

NB: Yes, this is some kind of decision matrix for plugin developers (wink)