Enhancement - Background of the system and maintainers

[mefranklin6]

Hello! This is right up my alley and I'm looking forward to reviewing this system!

Can you please add the following so people can judge the seriousness of this project? Where does it stand on the spectrum between a one-person vibe-coded project and a a multi-collaborator mature system?

Developer and maintainer background:

• A quick intro about you / your team. What's your background and experience?

Is this system in production anywhere in a commercial environment? If so, please list:

• Orgs that have this system in production
• How long has the system been in production there

Community:

• Stats about collaborators

Thank you!

[aarontodd82]

Hi! I'm an AV system designer and programmer with 20 years in the industry. I've programmed Crestron, Extron, Q-Sys systems but I currently focus on system design with my company. I'm a partner at Tri-Tronics AV, a commercial integrator in North Carolina, USA.

I am not a professional software engineer, but have been programming for personal interests since I was old enough to type :) This project comes from a deep understanding of what control systems actually need to do in real spaces and the issues the programmers face. The idea behind OpenAVC is that most spaces already have hardware capable of being control systems. You rarely need a dedicated black box.

AI tools have been part of the development process, but always under close direction and review.

Production status:
OpenAVC is not yet deployed in a commercial environment. I plan to spec it into appropriate projects through Tri-Tronics in the near future so that it can have some real field testing.

Community:
This is currently a solo-maintained project. This is my first real open source project, so I welcome guidance on best practices as much as I welcome code contributions!

[twnvrb-lgtm]

Reading this, I was more of the position of 'why wait to deploy it.' What I think is important is not having every module for every device. Early deployments can focus on the basics of what most venues need — something that turns computers, projectors, and PDUs off and on with an easy to use and manage schedule. Pair that with a staff interface to add or change devices and you have a foundational deployment.

I've built and deployed a system built on the same philosophy successfully. It has been bullet proof. Tailor the modules for your client.

Your UI is fantastic BTW. Looking forward to seeing more.

Let me know if you want to talk.

[nocarryr]

@aarontodd82 I've been digesting your code base whenever I've had time over the past few days because I've felt the same way about that gap for a long time too!
I love that you incorporated inter-process/mesh controllers in your design because it makes so much sense for commodity hardware (plus cross-subnet environments).

Hoping to find a few places to deploy very soon and I can already see some packaging/dependency/typing improvements that can make life easier for development if you're open to it (and once I've looked into things enough).

This all looks incredibly promising!

[aarontodd82]

@nocarryr absolutely, jump in on anything you see that can be improved! Let me know if you have any questions - I'm glad you're here!

[rod-driscoll]

@aarontodd82 I love what you are doing, I am of the same mindset as you and have been planning to do the same thing. One thing that I recommend is; now you have opened up to third party contributors then the main branch should be considered as production only so be untouchable via direct commits; all development should be done in feature/bugfix/dev branches which are merged into main via pull requests.

Here is an example project that implements the recommended workflow for contributing to open source projects, I recommend adding a 'Contributing' section to the readme linking to this tutorial project (or something similar): https://github.com/firstcontributions/first-contributions

[nocarryr]

@aarontodd82 I love what you are doing, I am of the same mindset as you and have been planning to do the same thing. One thing that I recommend is; now you have opened up to third party contributors then the main branch should be considered as production only so be untouchable via direct commits; all development should be done in feature/bugfix/dev branches which are merged into main via pull requests.

Here is an example project that implements the recommended workflow for contributing to open source projects, I recommend adding a 'Contributing' section to the readme linking to this tutorial project (or something similar): https://github.com/firstcontributions/first-contributions

I couldn't agree more. The PR workflow is vital to fostering a community.

Another great benefit in this is code review. A separate AI reviewer (like code rabbit.ai or similar) is a fantastic way to keep the main branch in a working state. With so much work being done by agents these days, it's become more important than ever (also it's generally free).

[aarontodd82]

@rod-driscoll @nocarryr Thank you both for the guidance! Main is now protected, and contributor changes go through PRs with CI checks. There's also a CONTRIBUTING.md and a Contributing section in the readme with the first-contributions link (#9). CodeRabbit is set up for PR reviews too. Keep the suggestions coming!

[nocarryr]

@aarontodd82
May I also suggest that you adjust your own workflow to using pull requests instead of committing directly to main?

I think you might find the feedback from AI code review incredibly valuable (see the comments in #13 for example). Plus it can prevent unforeseen regressions and bugs from hitting the main branch.

On top of that, it gives others insight into upcoming changes and makes it much easier to see the history of changes in the codebase.

It might be a bit of a shift for you in your process, but I'd recommend at least giving it a shot.