Community Project Guidelines and Best Practices

Here are a few guidelines to keep in mind while building and submitting your Aras Community Projects. If you’re looking for a printable PDF version of the Aras Community Project Guidelines, you can find it here.

These two articles about Best Practices for Community Projects also have some very useful advice. Best Practices 1 and Best Practices Part 2 go a little deeper to help you create the best Community Project possible. 

Projects Should Include:

1. Source Code

All Aras Community Projects must include the original source code. For example if you create an external application that interacts with Aras, you will need to provide the project source code in addition to any compiled code (dll’s, executables, etc). This is critical to sustaining a strong open-source community where members can grow and collaborate together.

2. Documentation

When it comes to documentation, we really want to see three things:

What does it do?

Describe what the project does. Is it designed to solve an industry-specific business problem? Does it streamline administrative tasks or enhance existing Aras functionality?

How do you install it?

Instruct the user how to install your project, from the point they download it to when the project is ready for use. Don’t forget to mention any preconditions/pre-requisites for the target Aras instance (ex: Tech Docs must be installed to Aras, or the server must have Visual Studio installed).

How do you use it?

Give the user the basic steps to use the project, starting from login.

Your project documentation doesn’t have to be a lengthy PDF or hefty MS Word doc – Aras Labs projects are documented using the README.md found in the root of every GitHub repository. Check out any Aras Labs project for an example, or feel free to use this readme as a template.

3. Attribution

Be sure to give credit where credit is due. If you collaborated with a team to spec out your project, or if you partnered up with a colleague to write the code, give them a shout-out when you submit it! And don’t forget to recognize any third-party vendors, developers, or designers whose work you may have used, especially if their license requires it.

Projects Should Not Include:

1. Intellectual property that is not yours to share

Do not include third party compiled code (dll’s, executables, etc.) or materials that are not licensed to be shared freely.

2. Aras feature license keys for subscription features and applications

Do not share subscription feature license keys or other subscription materials. If you have questions about the benefits that come with an Aras subscription, please contact our Community team at [email protected]. If you have questions about what content should not be included in an Aras Community Project submission, please contact Aras Labs at [email protected].

3. Freemium or limited-time trials of paid products

Do not include freemium or limited-time trials of products produced by you or your organization. However, projects that integrate with other paid services are acceptable.

Example 1: Does not meet guidelines

Harry from XYZ Corp. submits a 30-day free trial of the XYZ Connector, which requires a monthly subscription to continue funtioning after the 30-day trial expires. Since it’s a paid product, Harry cannot submit the source code for the XYZ Connector.

Example 2: Meets guidelines

Harry from XYZ Corp. subscribes to ABC, a third-party product he really likes. He builds a connector to use ABC with Aras, and then he submits the source code for his ABC connector – noting that users can try out the connector with ABC’s 30-day free trial.