I think there is an argument to be made for making the API a relatively high priority. There are numerous requests that come in that could be implemented by third parties if an API were available. There are plenty of requests that Jared and Ken will probably never get to because they are only important to a minority of their customers, but having an API would make those features possible without relying on Ken and Jared. For example, if the API allowed manipulating sequences, some of these recent feature requests could be implemented by others taking the burden off of Ken and Jared:
- Automatically planning astrometry targets
- generating mosaics based on the PI widefield mosaic script
- automatically generating flats targets for sequences with a camera rotator at varying angles
- sky flats
- planning targets for acquisition based on rise/set and transit times
Features related to observatory automation are often very equipment-specific, but could be implemented if an API were available:
- coordinating equipment power on and power off with running the sequence
- integrating control of roof and dome shutter with sequence (opening the roof early to start cool-down)
- re-starting an aborted sequence when weather stations report good conditions
These are just some ideas that immediately come to mind. I’m sure that new and interesting ideas would come up over time if an API was available.
To the degree that an API simply exposes existing features of the software (like manipulating sequences) it should not impose a heavy support toll on the developers.