Exploring How Open Source Contributions Shape App Inventor Extensions?

[Powell567]

Hi everyone,

I'm fairly new to the world of open source and just started exploring how different projects evolve through community contributions. Recently, I got curious about how the extensions available for MIT App Inventor are developed and maintained.

A few questions popped into my mind:

• How do open source contributors decide what kind of extensions to build for App Inventor?
• Are there any specific GitHub repositories or communities that focus solely on App Inventor extensions?
• What's the general workflow when someone wants to contribute a new feature or fix a bug in an extension?

I’d love to hear from experienced folks here. If you've contributed or followed the development of any open source extensions, it would be great if you could share your insights or even some links to active projects!

Thanks in advance!

[TIMAI2]

@Powell567

How do open source contributors decide what kind of extensions to build for App Inventor?

• personal requirement
• requirement of others
• spotting "a gap" that needs filling (things that can't be done with native components)
• the joy of coding to solutions

@Powell567

Are there any specific GitHub repositories or communities that focus solely on App Inventor extensions?

• nowhere specific. Some developers use githib many do not, some post their code on the community (here or on the other builder communities), others have their own websites/blogs to make their exntesions available. Some don't obscure the code in their extensions.

@Powell567

What's the general workflow when someone wants to contribute a new feature or fix a bug in an extension?

• generally they ask/comment on the topic where the extension is published.

n.b. I made this a wiki, so that anyone can add/amend to the lists I started

[Powell567]

Thanks

[Powell567]

Is There a Best Practice for Naming and Structuring App Inventor Extensions?

Post Content:
Hey everyone,

I've been going through a few open-source App Inventor extensions on GitHub lately to understand how they're built. One thing I noticed is that the naming conventions and folder structures vary a lot between projects.

So I was wondering:

• Are there any recommended best practices for naming classes, methods, or even the extension itself?
• How do experienced developers organize their files and codebase for maintainability and clarity?
• Does following a specific structure help when submitting to the community or when others want to collaborate?

I’m still learning, but I’d love to follow good practices from the beginning so I don’t build bad habits. Any tips, sample repos, or advice would be really appreciated.

Thanks in advance!

[Taifun]

This might help

##PLEASE READ FIRST## Posting a new extension to the community

Submission of new extensions The community has adopted a new approach to the posting of extensions on the community, and all new extensions are now put through an evaluation process. We do recognise that you have put a lot of time and effort into creating your extension. We want you to be able to present your extension in the best condition possible, as bug free as possible, with the best documentation, and the Power Users may provide you with several recommendations of how to improve your ex…

Taifun

[ewpatton]

From the MIT side, we publish all of our extensions via GitHub under the Apache 2.0 license. Each extension is on a separate branch in the appinventor-extensions repo, and people occasionally provide PRs to improve them. I would recommend if you are publishing extensions to prefix them with some name or ID so that if we eventually release a new component (e.g., Chart) it won't conflict with your extension name. Generally following our naming scheme as already mentioned by others helps the extension feel more a part of the system and therefore more familiar to users than using an alternative naming convention. For example, we try to avoid the use of underscores in names, everything is Pascal case (except parameters, which are camelCase), etc.