Adam asked a really important, even foundational question: How does Chattanooga.Digital decide what software to deploy, particularly as part of our portfolio. 

Generally, that's up to members, and we need a process for that. Here are just a few more specific thoughts:

1. In concept we can deploy any apps for a member as long as it doesn't negatively impact other members.
• Members must bear the cost of deploying apps. So, basically, if you want an app that's not in our portfolio, you have bear the direct costs to deploy, which may include a code review, particularly to assess dependencies, containerization, etc. Exactly how and how much we charge for this is TBD.
• All new apps should be treated as projects, especially any that are being considered for the coop's portfolio. Each project must have a sponsor who is responsible for defining requirements, getting other members with similar needs to join the project, and, ultimately, covering the costs. This exactly what Open Source Program Offices do.
2. We should probably have a "portfolio working group" to identify, prioritize, and research apps. 
• Within or parallel to that, we may need app-specific task force; an accounting task force, for example.
• All of that depends on having members who are willing to either (a) volunteer to serve and/or (b) pay others to do this work.
3. I think it will be critical to have a pretty solid portfolio at launch because access to apps is what's going to drive interest. Yes, some folks may join because the believe in what we're doing. Most people will join because they want to do something or use some particular app. 
• Personal/family apps will likely drive most of our membership, apps like Actual Budget, Firefly III (accounting), Grocy (or Mealie), Home Assistant, Immich, PaperlessNGX, etc. 
• Business apps... accounting, CRM, digital marketing, HR/payroll, process automation, etc., etc.
• Community app: audio streaming, event management/registration, mapping/geodata, social media, video sharing, etc.

It will be important to get stakeholder input on these things. Of course, we have to assume our stakeholders are totally clueless and unable to provide meaningful input. That is one a primary reasons for doing Hack Sessions, to hear from [prospective] members about their issues and give them an opportunity to test-drive some options. 

Our business plan and bylaws/charter should clearly address these issues... I'm working on that.

Any thoughts, suggestion, or feedback would be greatly appreciated!