ODE

From CSTART Wiki

Jump to: navigation, search

Contents

[edit] Overview

Open Design Engine (ODE) is the working name for a proposed joint software project between CSTART and Mach 30. The goal is to create a web based engineering project management system to facilitate the design and development of openly licensed hardware projects at CSTART, Mach 30, and elsewhere. The initial discussions from the forum can be found here.

ODE will be openly licensed (the choice of license is still being discussed), and will be distributed similar to Wordpress. That is there will be a version available for download that users can install on their own servers (like wordpress.org) and a hosted version where users can register accounts and host projects (like wordpress.com).

[edit] Guiding Values of the Project

The following values are intended to shape the development of ODE. Ideally decisions will represent a balancing of multiple values. Note, these values were derived by reflecting on the views (or positions) presented during the early discussions about ODE at Mach 30 and CSTART. See the Mach 30 consensus process for more info on values and positions. Note, these values are listed in no particular order, the numbering is simply for easy reference below.

  1. We need something that works better than what we have now - CSTART has the wiki+forums+polls+version control system?, Mach 30 has its forums+phone bridge
  2. Getting something sooner would be better than later - there is a sense that current projects will gain momentum from having the right tool for engineering management, which would be a "very good thing"
  3. It would be better if we can share the work and the rewards of developing this system - this includes both between CSTART and Mach 30 and with the larger open design/hardware community
  4. Release early, release often - this has been the mantra of other successful open source projects, and is in support of having something "sooner rather than later"
  5. The defining feature(s) include the ability to manage engineering decisions - we need to focus on those features that hardware projects need that platforms for open source software development do not provide
  6. The language used for the software must be one that is familiar to developers in our communities - you can't write in a language you don't know
  7. The choice of programming language (and other elements of the software stack) impacts the ability of users to self-host, and all other things being equal, the barrier to self-hosting should be as low as possible - this value strongly supports choosing tools that are widely available if at all possible (such as the LAMP stack)
  8. Proposed but not discussed - Site security and information assurance should be a high priority - organizations in the US will need their hosted versions of the tool to be secure enough to meet ITAR and other export control restrictions

[edit] Key Decisions to make

The following are the key decisions to make, and the values that must be balanced to make them.

  • Should we extend an existing system, or develop something from scratch - Extending an existing system may mean getting something useful much sooner, but it means accepting many decisions that are already made (language, license, architecture, etc). Values to balance include: 1, 2, 4, 5, 6, 7.
  • Development Roadmap - Emphasis should currently be on selecting feature sets for early versions that get the system off the ground and let users start seeing benefits sooner rather than later. Values to balance include: 1, 2, 3, 4.
  • License - The license of a project can evoke a strong reaction from the community, so the choice of license should be made to support the shared values of sharing source code of both CSTART and Mach 30. If ODE is based on an existing system, this decision will be made by default. Values to balance include: 7 (and likely one or more uncaptured values).
  • Programming language - Language choice affects developer availability, barrier to hosting, and more. If ODE is based on an existing system, this decision will be made by default. Values to balance include: 6, 7.
  • The code repository for hosting the ODE source code - TBD

[edit] Potential features

  • Core Features (merging of major features/ideas from Mach 30 meetings and posts on CSTART forums)
    • Host Projects and sub-projects (sub-projects should be first class entities with their own members, documentation, etc but parent projects should have views that merge sub-project data with parent data when desired)
    • Projects include storage for:
      • Documents such as Bill of Materials, instructions, reports, etc (probably stored in wiki-like system that includes multiple formatting filters to give content creators control over level of complexity of input vs necessary control)
      • Revision Control System to store source code for embedded systems or stand alone software projects (should be accessible directly through RCS interfaces and through web pages)
      • File storage for part models and final part drawings (still version controlled, but maybe not in the same space as the source code)
    • Users should be able to configure features used in the project
    • Project "home page" should be wiki-like as well to let project owners "sell" their projects, including posting rich media (videos, pics, etc); More like OpenRocket's home page than its sourceforge page - think public face of the project
    • Projects should also have dashboard page so members can keep up with progress (possible example) - think members' homepage for the project
    • Projects need workspace/forums to discuss design and development issues (especially for hardware) that includes linking files to comments and the main post to store the evolution of a design decision
    • Need Issue tracking, and it would be very good if it included way to directly request (and advertise) help with specific tasks/sub-tasks of the project
    • Site level homepage should highlight best hosted projects (like wikipedia does with featured articles?)
    • Projects should have a news feed (blog?)
    • donation drive module
  • Newer ideas for features that need even more discussion to fully define
    • One possible engineering workflow (project features should support following all or part of the workflow as needed by the projects):
      • get/make requirements (to understand what you are going to build)
      • setup 1 or more teams/sub-projects (small scale still just 5-10 people all one team, big scale several sub-project teams)
      • create tasks that link to derived requirements to establish traceability, in multi-team scenarios, tasks should be associated with the appropriate teams/sub-projects; in single team scenario, all tasks should get associated to the main team/project when there are multiple teams, usually need a PCT (team of teams)
      • loop through below, each iteration move into more detail (lofi analysis, hifi analysis, cad parts, prototype, build, fly)
      • do work (each iteration = more detail: lo-fi analysis, hi-fi analysis, produce cad parts, prototype, build, fly/test) <–if we're generalizing
      • document (examples: procedures, BoM, drawings, parts, analyses docs, graphs, reports, meeting minutes, presentations, Requirements docs, etc)
      • review/test
      • update design
      • approve – triggers next iteration
    • Project assistance Bounty System – mash up of craigslist, sourceforge, rent-a-coder, and a solution archive. The ideas is to have a website where "customers" can post discrete analysis, report writing, peer review, hardware build, component design requests, etc. – see http://mach30.org/blogs/jrs/2009-10-22-ispcs-2009-day-1-mission-and-methods for details. This is an attempt to discretize hardware development like wiki has discretized encyclopedia writing, enabling users to hop into a project to answer a specific need.
    • Have a fans page so supporters can show their interest
    • Auto-share buttons for social network sites from project pages (to share on reddit, twitter, etc)
    • Bug/Issue tracking (duh) – should be tied to the bounty system if used?; taggable, with tags auto added for type of issue and project hierarchy (this project + parent project tags)
    • A BOM tree to visualize the structure. Also, a method to see where a part is used in other assemblies.
    • Workflow system should be extensible and allow users to share there workflows with other projects (this way we are not expected to deliver the end-all-be-all workflow, and instead, the community can discover what workflows work best in the tool); system should ship with some basic workflow(s) in this case so it has something even at release
    • Engineering file management features - Source code control for embedded systems or computer based controls, etc should be stored in one of the available Version Control Systems (VCS) such as SVN, bzr, git, etc. But engineering documents offer challenges that VCS do not handle well (very large, on order of GB files, primarily binary files). Here are some specific requirements for engineering documents. (Should investigate Enterprise CMS like Alfresco for underlying capabilities, as many of the features below are available in this class of tools.)
      • Easily manage very large files (on order of GB)
      • Easily handle binary files
      • Find a way to keep binary files (like drawings) from entering conflicted states (one option, per rpulkrabek's comment on the forums is to allow users to mark files as in use or checked out to indicate that other users should not work on those files)
      • A method to inform others, and possibly restrict others, that a certain item is currently being worked on, to avoid different design changes happening at the same time.
      • A history or RSS feed of the most recently modified items.
      • Document number generation. Possibly a running number to uniquely identify each document or part and possibly associate this number to the document. If this method is used, it's suggested that the number is also associated to a more readable description ex: ID=12345678rev01; Description=OHKLA COMBUSTION CHAMBER. Another thing to consider is variants and the numbers for that.
      • Thumbnails next to each item to quickly view what each file is (useful for CAD models).
      • A page/site to see all available attributes, such as, ID, Description, Creater, Modifier, creation date, modified date, etc.
      • Configure file storage so all files in the project (including attachments to issues/forum posts, source code VCS files, and files specifically loaded into the engineering file management system) are stored in the engineering file management system. Attachments should include link back to page where they are attached in the meta-data for the file. The idea is that all of the files wind up in a central location for easy search/backup, but are still available on the page where the context about them is located.
    • Add real-time wiki editing (like Etherpad or google docs). See list of existing tools
    • Add web based IRC client with server for hosted projects and have IRC sessions auto-logged to the project space
Retrieved from "http://cstart.org/wiki/ODE"
Personal tools