CSS all pages

Technical FAQ

01. Where do I find the open source applications on the OSADP?

You can find open source applications by clicking the “Explore Applications” button on the home page, then browsing or searching for the desired application and click on the name of the application name.  Alternatively, enter the desired application name or a keyword related to the application in the search field at top of the screen.  Following a search result, it will lead you to the application page where you can download the open source code packages of interest.

02. May I freely use and distribute the open source applications I downloaded from the OSADP?

Each open source application that is posted on the OSADP comes with open source license information including terms of use for the released source code. This information is included in the zip file that is downloaded. Please read and understand the terms and conditions before starting to use it.

03. I have encountered a technical issue with an open source application. Where can I get help?

A good place to start is the “Discussion forum” under the “Community” menu. Typically, when an open source application is released, a discussion topic is created in the discussion forum cto failitate communication between the developers and the users.  You are encouraged to report any issues and defects you find with applications you have downloaded in the Discussion forum under sub-topic labled Issue Tracker for that particular application.  Developers are likewise encouraged to check this forum periodically.

04. Where are the in-development applications kept?

In-development applications are stored as ‘projects’ in private repositories on GitHub. To access projects, collaboration status must be requested by completing a “Project Collaboration Request” under the “Open Source” menu, and approved by the project’s manager. The project’s manager determines when the application, once completed, is ready for release onto the OSADP. Once released, the open source application is available for download on the OSADP.

05. I have a great open source project concept. How do I get it started?

A new open source project must be deemed appropriate before it can be created.  The first step is to complete the New Project Proposal form, can be found in the footer section. This form requires you to enter your name, email address, telephone number, organization and a message describing the project idea. This information is routed to the OSADP sponsors for consideration and approval.  Open source code resulting from approved projects will be hosted on GitHub as an OSADP private repository. The open source code packages are not released to the OSADP repository until the developers determine its readiness.

06. How can I contribute to an existing DMA active development project?

Your talents as a developer are important to these projects and we appreciate your interest in contributing to the DMA program. To contribute, please complete the Open Source Collaboration Request form located under the “Open Source” menu item. OSADP administrators will review and forward it to the appropriate people for approval and respond back to you with access information so you can begin contributing to these projects.

07. I made enhancements to an open source application I downloaded from the OSADP. Can I share/post them back to the OSADP?

The first step is to request contributor status for the existing project by completing Open Source Collaboration request form shown at the footer section of each page. Once you become a project member, more instructions will be provided by the project lead. 

08. Is there a good location that I can get transportation data to support the development and use of the OSADP applications?

Yes, the USDOT  through the Data Capture and Management program has developed the Research Data Exchange or RDE to share transportation data and promote the sharing of both archived and real-time data from multiple sources (including vehicle probes) and multiple modes. This is a excellent location to look for highly documented transportation data to support the OSADP applications. 

09. I have a completed application that I want to upload to the OSADP. What do I do?

The process for uploading an application to the OSADP is documented here.  Some highlights:

  1. You must be a registered user to upload applications to the OSADP (Register here).
  2. You must have a GitHub account (sign up for a free Github account here).
  3. You must complete an Open Source Upload Request form to express intention for sharing the code base as open source on OSADP and agree to the terms and conditions of the website.
    This form requires you to supply basic information about the package for a preliminary approval review
    • Submitter's name
    • Github username
    • Organization/Company
    • Email
  1. The OSADP administrator, in conjunction with USDOT, reviews and grants approval for upload.
  2. After approval, submitter is given access to a private Github repository where they can upload their zip file. Uploaded packages must conform to the guidelines and formats that include the following basic elements:
    • Source code or assets
    • README.txt (template) gives user a brief summary of the open source package and provides other useful information
    • RELEASE-NOTES.txt (template) describes incremental differences in each release and associated instructions
    • LICENSE.txt (sample) declares the license that this open source is released under and discusses associated terms and conditions
    • ATTRIBUTION.txt (sample) acknowledges or gives credits to individuals, a group, or an organization that have contributed to the open source

 

RELEASE-NOTES.txt (template) describes incremental differences in each release and associated instructions

10. The application I want to upload includes multiple components. Does that change how I would upload it to the OSADP?

Not necessarily. In these situations, you are encouraged to contact the OSADP portal administrator (contact us) notifying them that the package includes multiple components. At this point, the OSADP portal administrator will work one-on-one with the submitter to ensure that their application is released in the most streamlined way possible. In general, for complex applications that include multiple components, the OSADP administrator recommends that the submitter take additional actions when uploading:

  • Consider and identify what components are the most relevant to potential downloaders. Also consider what you have permission to share, as some components may have been developed external to your project.
  • Consider documentation beyond the minimum requirements (license, readme, release notes and attribution) to help potential downloaders. For example:
    • A diagram depicting the data flows/relationship between the components that are part of the upload package
    • Definition of the interfaces of components that ARE NOT a part of the upload package
  • The uploaded package should include primary source code, instructions and documentation, and NOT external binary components e.g. executable files. The package file size should be less than 100 MB.
  • If a component can be cleanly separated from the uploaded application , and has value for other systems, the uploader may wish to submit a separate upload request and upload that component to a separate Github repository.

Components that are commercial or independent, e.g., virtual machine image, code library (.dll) files, binary code – should be treated as separate components from the uploaded package and should provide sufficient instructions for integration or re-assembly.

In addition, there is a discussion forum topic for OSADP open source uploader regarding uploading complex applications. Uploaders are encouraged to review and contribute to this forum.

11. I noticed an “Alpha” release of an application on the OSADP. What is an “Alpha” release?

An Alpha release of an application indicates an early version that may not contain all of the features that are planned for the final version. Standard software testing follows two stages before it is considered complete. The first stage is alpha testing, which is typically performed only by users within the organization that developed the application. The second is beta testing, which involves a limited or controlled number of external users.