The ASCOM Initiative was formed in 1998 with objective of opening up the astronomy software ecosystem via a set of open standard interfaces, one for each commonly used astronomical device. Furthermore, the design of these interfaces is strongly based on minimizing differences between individual devices of a given type from the perspective of the application developer. The ASCOM standard interfaces benefit not only the application developer, however, but also the device developer. By offering a standard interface to their device, it automatically becomes "supported" by all existing ASCOM compatible applications as well as those which may appear in the future. These benefits also accrue to the general astronomy community through more consistent operation and setup.
Along with the interface definitions, a set of libraries, utilities, and tools were developed with the goal of promoting and easing the task of writing both applications and device drivers. These libraries, utilities, and tools evolved and grew considerably over the last twenty years, and are now available as the ASCOM Platform (the libraries and utilities) and the ASCOM Developer Tools (the tools). The Platform is an end-user installation for supporting applications and drivers, the developers of which often use the Developer Tools to ease their tasks. The result of this activity and philosophy is a widely accepted industry standard for astronomy software integration.
Most astronomy systems consist of several components that communicate with each other, a distributed system. All modern non-trivial systems are distributed in this sense. The design and engineering discipline needed to effectively create distributed systems always starts with interface definitions. The process of designing an interface is always subject to negotiation between the providers of the modules. The ASCOM core team has the independence and depth of experience to ensure the outcome is fair and maximizes overall benefit. ASCOM's core goals are to establish interface standards and provide enabling technology that makes it easier to adopt the standards.
This document clarifies how the ASCOM Initiative is structured to deliver its goals and continue the success of the last twenty years; delivering benefits to a wide range of individual hobbyists, educational institutions, astronomy clubs, manufacturers, software authors and government agencies.
The ASCOM Initiative operates as a cross-functional core team organization. Core team members have a dual responsibility; they are responsible for the ASCOM Initiative achieving its goals and they are responsible to ensure that the deliverables comply with the ASCOM standards and also adhere to best practices. One team member is designated as Lead Engineer, and has the final say in arbitrating technical decisions. This setup continues to be used due to convenience and the fact that it has worked fine this far. It is not because someone thinks of it as a superior project leadership model.
There is no legal entity. The ASCOM Initiative is just some people scattered around the globe with the common goal to produce excellent interfaces and supporting libraries, utilities, and tools to support astronomy. Any copyrights in the project are owned by the individuals and organizations that wrote those parts of the code. Most of the code is currently released under a Creative Commons license, but this is under review. If it changes it will do so to make use of the open source code even less restrictive. See Ownership and Licensing for more info.
nterface and protocol designs and changes will of course need to be acceptable to the application and device communities. It is expected that the device community will push one way (complexity and special features) and the application community the other (simplicity and commonality). This negotiation process will be arbitrated by the Lead Engineer, who has the final say. Only showstopper objections will be considered thereafter. This strictness is due to the broad effects that a poor interface or protocol design can have into the far future.
Lead Engineer: The person who has the final say in moderating decisions, adopting designs, approving implementations, and fostering communications. The person responsible for the long term results, the lead engineer, must have the final say in any decision needing moderation. Ideally the lead engineer should have a strong background in both software engineering and technology team leadership and management. The responsibility is a great one. The lead engineer is part of the core team (see below). Membership in the Core Team is by invitation.
Core Team: A small set of volunteers who meet regularly and make decisions on process and plans for the future. Most are also Maintainers (see below). Part of their responsibility is to periodically survey the application and device developers as to their satisfaction, and to receive requests for changes and additions to the interfaces and protocols from the working groups.
Maintainers: A maintainer in the ASCOM Initiative is a volunteer individual who has been given permissions to push commits to one of the Git repositories. Maintainers are free to push commits to the repositories at their own will. Maintainers are however expected to listen to feedback from users and any change that is non-trivial in size or nature should be brought to the project as a proposal to allow others to comment/object before merge.
If you think you can help make the project better by shouldering some maintaining responsibilities, then please get in touch. You will be expected to be familiar with the ASCOM Initiative and its ways of working. You need to have gotten a few quality patches merged or have produced a quality tool or utility as a proof of this.
Former Maintainers: A maintainer who stops being active in the project will at some point get their push permissions removed. We do this for security reasons but also to make sure that we always have the list of maintainers as "the team that push stuff to ASCOM". Getting push permissions removed is not a punishment. Everyone who ever worked on maintaining ASCOM is considered a hero, for all time hereafter. Thank you for your service!
Advisors: When an interface is up for review, usually due to inputs from the community, the core team will always solicit advisory input from application and device developers who will be affected by any revision. Advisors have the function of making certain that the requirements for the device type or for applications are (or will be) met by the interfaces, libraries, utilities, and tools produced by the core team. They will usually be representatives of companies and individuals who make astronomy devices and software applications which are used by multiple people. Once the revisions have been agreed-upon, implemented, and tested by both core team and advisors, the advisor team will disband. Our goal is stability so this should be a relatively infrequent need.
Advisors have a higher priority in design decisions compared to Maintainers. If you develop astronomical devices or astronomy applications, we encourage you to be an adviser when you see an invitation so that your voice, and those of your customers, will be heard.
Server Admins: We run a web server ascom-standards.org and several discussion forums on Groups.io. The server as well as the Groups.io services are paid for on a voluntary basis by one of the core team. In addition there is a core team member who is the primary maintainer of the web server and content. Other members of the core team may make changes. The server is regularly backed up offsite, and the content is also in the primary Git repository.
Forum Moderators: An important function of the group is to keep communications on the forum within the Code Of Conduct, and to prevent the forums from being blatantly used as advertising media for vendors. This is the role of the forum moderators. Requests to join the forums are subject to approval, and new members' posts will be moderated. Moderation accept/reject decisions are the responsibility of forum moderators. They have the final say. A moderator may be any volunteer from the community who has shown himself to be a good judge of content. Approval for moderator status will come from the core team.
Evangelists: These are the people who are responsible for educating the community as to the objectives, methods, and reasons for ASCOM overall, and for the specific technology. The evangelists give talks, video interviews, make educational videos, and write documents that cover the non-technical aspects of distributed systems and the role that interfaces play. The evangelists are also responsible for defending the honour of the ASCOM mission and technology in the face of attempts to discredit the organization and/or its activities.
There are four forums which provide the primary communication channels for the ASCOM Initiative. They are (in no particular order)
In addition, periodic surveys of developer satisfaction will be conducted (link leads to latest surveys). These surveys are intended to measure our results, not to provide another channel for requirements and suggestions. Those will come from the Working Groups. Finally this ASCOM Initiative web site is a primary outbound channel of communication to both the general astronomical community and to the developer community. Finally there is an ASCOM Initiative Facebook page on which people can interact in a social media context.
Basically we want to assure that everyone associated with the ASCOM effort acts professionally and is respectful in disagreement. Specifically:
The expectation is that the majority of issues will be resolved informally. However, if a matter cannot be resolved informally, the moderators reserve the rights to:
It's assumed that you are already a member of the ASCOM User community. So first join the ASCOM Driver and Application Developer Support Forum. Read up on details and get familiar with the issues and environment there before you post questions. Follow generally accepted forum etiquette and the above Code of Conduct. If you have a specific project in mind, ask about it there and determine that it isn't already being worked on or hasn't already been done. You must be familiar with Git. Consider clicking 'watch' on the GitHub ASCOM Repositories that interest you. Then dive in! There will be a separate Contributor's Guide available, but until then use common sense.
For details on this process, see the info on this in the Standards Process section
The community of ASCOM Initiative volunteers who provide our tools to the astronomy community must be protected, and the community's trust in our work products must be preserved, if we are to continue to have such volunteers contribute their knowledge and provide us all with their services. Standardization of the ASCOM and Alpaca interfaces is critical to the community and supporting volunteers. To protect the integrity of the interfaces and supporting tools, the names ASCOM, ASCOM Platform, ASCOM Remote, and ASCOM Alpaca, as well as the ASCOM and Alpaca logos shown below (with or without text), are reserved by United States Common Law usage for the work products of the ASCOM Initiative as published on this website and elsewhere. These may only be used in accordance with our logo/marks policy as described in the Requirements area under Name and Logo Usage.
Any effort to undermine the efforts of the Initiative, or to confuse the astronomy community by using these names and/or marks in association with interfaces and/or tools that do not comply with the Initiative policies and standards will be met with public legal action.
