.

What are different stakeholders and their needs? What are their motivations and concerns?

There are a variety of software products that accomplish similar things around the world, and a lack of coordination.

Code is often written for the specific needs of a single agency rather than being built for transferability.

Agency-owned code is often not well-maintained. When it is, different agencies pay for consultants to fix their specific code, when it could be easily consolidated.

Why not have a piece of software that we are all constantly improving, instead of fixing when hired for a specific project.

Value propositions:

• exposure
• higher software quality
• efficiency of money and time
• [ some other points were missed in the dictation to notes ]

Useful Roles for Zephyr

Endorse a “Toolbelt”

So that as much as possible we can focus our efforts on knowing the same tools.

• preferred languages
• preferred data standards
• preferred support packages [ e.g. pandas ]
• preferred testing / integration suites

Considerations:

• Choices should accessible for an average student.
• What can more people contribute to?
• Standards are about 25 people agreeing with something, not someone saying their going to write a standard.
• The “best” is the one that is mostly used. The usage will say what’s more relevant.

Develop a funding mechanism

Software “Membership Fee”
Each agency could put a fixed amount of money into the foundation and a % goes to improvement and maintenance of a suite of “Zephyr Projects”

Improvements would include:

• adding and improving documentation
• simplifying and improving code

Project “Membership Fee”
Each agency gives a fixed amount of money to a specific project to be built with the pooled money.

Considerations:

• Chicken and egg situation: if we had a good project already established we could use it to attract the funding. If we have funding we can do the cool projects. How to start them?

Write Rules

Have a clear contract to both contributors and clients.

Ensure Quality

Conduct testing of the software to guarantee that it works in different situations – have a quality control group

Considerations:

• After 10 years it will need to be re-written and updated. Who will do that?
• Extensibility and use of common data standards and APIs should be encouraged.

Manage Development and Maintenance of Specific Products

Zephyr could issue contracts. Agencies would give money to Zephyr to maintain the different/common software. Zephyr would contract with consultants.

Zephyr should own the repository. They should organize and maintain, and add the contributions to the repository.

How transferable are models and who owns the model? If a specific entity owns it efforts can be optimized.

Structure Project Management

Develop a clear management structure to keep, maintain, and update Zephyr software projets.

Define the required resources: monetary and human.

Considerations:

• For the project to survive you need the owner to be committed to keep driving (being responsible for) it.
• Incubated project may be different than an established one.

What types of projects should be candidates for incubation?

Zephyr should also keep software in different stages of development: having both an incubator and a platform for more developed software.

Considerations:

• What would be the easiest one to succeed? The smallest one or the biggest one?
• Should have a history of being open source
• Robust code
• Easily extensible [ no single giant class ]
• Enough users
• We cannot put all efforts in a single model.

ActivitySim could be a good starting point. OMX APIs as well.

What priority/urgency should software development have compared to others for Zephyr?

–