Frequently Asked Questions concerning code contributions

If we need to modify source code for our organization needs, is it possible?

• Please, get in contact with SOS before modifying source code. We are open to the needs of our community and are therefore interested to know what functionality you miss.
  • Particularly applies to our products the saying: there's more than one way how to do it.
  • We would like to discuss your business needs and organize code modifications in a decent Requirements Management process. 
• The GNU Open Source license permits the modification of source code for users of the that license.
• Users of commercial licenses should submit their change requests or code contributions to SOS. Such modifications affect warranty and support of the products and are not accepted without prior written consent of SOS.

What is the standard procedure for code modification?

• Code modifications by users of open source licenses
  • Code modifications can be submitted as feature requests to the public SourceForge Ticket System either as requests for development by SOS or as code contributions.
• Code modifications by users of commercial licenses
  • Code modifications are usually effected by the SOS Development Team, not by the customer. However, we will review code contributions of customers.
  • Users of commercial licenses submit their change requests to SOS. The procedure is the same for change requests that are to be developed by SOS and for code contributions of customers. The SOS Ticket System offers the issue type "Change Request". Such requests will be initially reviewed and answered by the SOS Support Team. 
• Procedure for Change Requests
  • If a change request is accepted during the initial review by the SOS Support Team then it will be added to the Requirements Management System.
    • The process to manage requirements includes legal aspects of code submissions and technical aspects of quality of code and maintainability. 
    • Requirements are elaborated by the SOS Development team and are subject to a final review by SOS and the initiating user or customer.
    • At this stage the customer or user will receive approval or denial for submitted change requests.
  • Change requests with valid requirements are added to the public Change Management System.
  • During the Release Planning period decisions are taken if change requests will be added to the next release, to a later release or will be postponed.
    • Change requests based on paid development will be preferred and are assigned a fixed release date.
    • Change requests that attract broader feedback from the community are equally preferred.

Do we need to get approval from your company?

• Users of the open source license do not need approval from SOS for code modifications, they are free to modify the software at their will within the limits of the GNU GPL. However, SOS will not accept to add such modifications to the source code of the products if the above-mentioned processes for Requirements Management and Change Management were not considered.
• Users of the commercial license will loose warranty and support for the products if they were to modify the source code without consideration of the above-mentioned Requirements Management and Change Management processes.

Could we get maintenance & support for all modified packages if they were approved by SOS GmbH?

• Yes, definitely. It is the purpose of the Change Management process that would allow us to support and to maintain such modifications.

Could we share this code with other clients?

• Certainly. Within the limits of the GNU GPL you are free to share your modifications. 
• Please, consider that sharing does not include selling such modifications or bundling with commercial products.

Is it possible to have ownership rights for the packages and extensions that were developed by our personal?

Community Contributions

• Community contributions are essential. They prove that this is a living project.
• Your contributions are valuable and important for the dialog between users, maintainers and developers.
• In the following chapters find a list of ways that you, the members of the JobScheduler / YADE community, can help improve the products you use.

Community Services

Early Adoption

• Use Release Candidates with upcoming releases and report on your experiences.
• Try out Candidate Features that are not yet included in releases.
• Report usability issues from early adoption.
• Please let us know if you would like to share our Early Adopter Program and send an e-mail to: community@sos-berlin.com

Bug Reports

• Report bugs in our ticket systems, see our Community Resources page for more information.
• Suggest workarounds that would bridge the time until the next maintenance release.
• Install maintenance releases and confirm problem resolution.

Feature Requests

• Let us know the real world situations you have to meet. 
• Add user stories to your feature request - this will help us to better understand the functional requirements.
• Let us know of your interest in specific features. This would provide us an estimate of the relevance of specific features. 

Code Contributions

• We do accept code contributions. However, some rules and regulations have to be considered to guarantee the quality and maintainability of the products.
• For more information see Code Contributions

Community Membership

• Become an active member of the Open Source product community.
• Receive access to voting for articles, to commenting and editing of articles to chat sessions.
• Please, apply for Community Membership

Community Feedback

• Your feedback is important to us. We will try to consider your propositions, particularly if we receive similar responses from many users.
• Please, participate in our surveys and send us your Feedback
• Yes, if you created Add-Ons or Extensions yourself then you will have full ownership of the results.
• Add-Ons and Extensions are independent modules that do not include code of the Open Source products. Such Add-Ons and Extensions can make use of public APIs of SOS Open Source products.
  • A good example would be an Extension that makes use of the official XML interface to integrate SOS products with other applications or usage scenarios.
  • A bad example would be a reporting solution that relies on the database and respective entity relationships that are used internally by the SOS product and subject to on-going change.
• Should Add-Ons and Extensions be shipped or bundled with SOS Open Source products then the respective rules of the GNU GPL for license compliance will apply.