Inedo’s Open Culture

Inedo is committed to maintaining an open culture. We believe you have the right to see “inside” our products and processes and to contribute to them.

Open Source Software

Romp, our UPack platform, and the Inedo Den product extensions are open source, and we actively accept and encourage pull requests. Take a look at our GitHub repositories to learn more.

The rest of our code—including our core products and libraries—is also open source, and you can access them by requesting access to our private GitLab repositories.

Open Roadmap

Our software is by no means “feature complete”, and we always working closely with users and thinking of ways to improve the software and add features.

Bug Reports and Feature Request Process

Is one of our products missing something you need? Is there a behavior quirk that is causing you lots of headaches? Our open initiative includes our feature request process (and some few helpful tips).

Bug reports should be submitted to the Issues section of the project’s corresponding GitHub repository if one exists, or filed as a support ticket if there is no corresponding repository.

Before submitting a bug report or feature request, please perform a quick search of both the associated GitHub repository (if it exists), or the YouTrack instance for non-public projects to ensure someone else hasn’t already submitted the same item.

Open Change Management

We track our core product and shared library changes using a cloud-hosted YouTrack instance. You can search by product, status, and version number to see what was changed or will be changed in a release.

Pull Requests

We are happy to consider pull requests. The guidelines for pull request consideration include:

• Bug fixes of any kind (obviously the more trivial the code change the more likely we are to accept quickly)
• Minor features or usability tweaks that have little or no impact on documentation
• Must not contain large non-functional changes (i.e. please don’t rewrite the entire project just because you don’t like the coding style)
• We’ll consider refactoring changes so long as they provide some tangible benefit in maintainability, but it would be best to start a discussion with us before starting something like this
• Must not add major new features, change current behaviors, or otherwise render our current documentation totally incorrect

We obviously will not accept pull requests that violate or our own license terms or that require additional licensing restrictions beyond the associated project’s license agreement.