The "what you need to do" sections of "Welcome contributors" and "Require review of contributions" lack guidance regarding budgeting for outside contributions

[ericherman]

Codebases start with a small set of contributors, possibly a single small development team.

Without guidance regarding reasonable expectations of budget for possible outside contribution, the Standard for Public Code could be interpreted as creating a larger demand upon the initial developers than is likely intended. Also, without any time budgeted for review of new participants' contributions, these new developers will not be able to genuinely contribute.

Some guidance in this area could help make implementing the Standard itself more easy to reason about and (more importantly) help to ensure that initial procurement is sufficient.

[ericherman]

Thanks @jgroenen for prompting thinking about this issue.

[joeribekker]

We (Maykin) also struggle with this in our maintainer role.

We currently use the budget generated by clients of the software in our role of supplier. However, this creates a direct dependency between our role as maintainer and our role as supplier. Worst case would be that we have no clients in our role as supplier, and therefore no budget as maintainer to review external contributions.

We considered the following options (in no particular order):

1. Provide partner-support for suppliers to generate budget for us as maintainer
2. Simply accept that we need to be both maintainer and supplier, and use supplier revenue for maintenance budget
3. Rely on paid feature development and reserve some budget for maintenance
4. Rely on donations of suppliers or clients (even if they are not our client)
5. Setup an independent organisation (association/foundation) where organisations (users of the software) can be a member of and pay a certain amount periodically

We currently use a combination of 1 - 3 but ideally you want to get rid of 2 and 3, and rely more on 1 and 5. At least, in our case. Specifically number 5 since our target client is mostly the government.

[jgroenen]

For the discussion this afternoon, some thoughts I had:

• define the type of contributions you are open to, both in form (code, sketches, written ideas) as in how you will deal with them (as inspiration, as backlog item, as working code, ...)
• define the workflows and templates (per type) for contributions
• maybe have some way of suggesting contribution types and workflow suggestions

Also, maybe a planning or roadmap for when you are planning to accept and/or facilitate different types of contributions.

[Ainali]

Here is the summary of the community call: https://blog.publiccode.net/community%20call/2023/05/08/notes-from-community-call-4-may-2023.html Ping @jgroenen and @MattiSG.