Thanks for pointing to that related discussion, @pilou!
Just like some things I described above from a general perspective and as more of an observer until now, your and @dachary’s misunderstanding on switch of programming language, highlight the need for changes to the community organization in terms of:
- Responsibilities, process, governance, decision-making, structure, …
The objectives in terms of openness, transparency, flat hierarchy, ‘anyone-can-take-the-initiave’, etc. make this a non-typical FOSS project and poses unique challenges to community-building. The question is - in order to improve - as rightfully say:
If I look at the DAPSI information at my disposal, there’s not really make mention of these community-related aspects as being eligible for funding. There should be a Research Component and a Development Component. Though there is some implicit reference in the DAPSI Guidelines for Applicants in this statement:
“What can you do to make the internet more open, and help people take back their data?”
Arguably an open community that allows people to be actively involved in this goal fits the bill. In any case a DAPSI renewal should have the R&D components to be eligible and these should extend / build upon those that were described in the first submission.
For adding a ‘professionalisation’ of the community organization I see two options:
-
Organization component: There will be de-facto (need not be very explicit) a third component. First DAPSI submission has led to a solid project foundation being laid for the project as a whole. But for the new, ambitious R&D components we need to build further upon that to establish a well-oiled community process, which includes a concerted effort to get more people involved, contributing productively.
-
Research component ‘piggybacking’: The acknowledgement and argumentation that the FedeProxy development and community processes are an intricate part of delivering production-ready project deliverables on an ongoing basis, and possibly remain relevant to clients of the project after they’ve put FedeProxy into production on their code forge.
The 2nd option is interesting to explore. Some observations related to this:
- The express primary objective to serve and strengthen FOSS projects and their related communities.
- The fact that any software development project has a development method and process.
- Many commonalities exist between processes and that social activities may be unified.
- Application domains relating to software development have lotsa overlap, can be captured in vocabularies.
- FedeProxy has mentioned dogfooding at various places, and this can be an opportunity to achieve that.
- What are FedeProxy deliverables? Along with software, there’s open standard(s). There can be open process too.
Another stated goal seems to go against option 2 (paraphrased):
- “FedeProxy will dissolve itself after forges have adopted its work. There’ll be no longer a need for it to exist”
I wonder if this is really the case. Consider this:
- Will the open standards further evolve, need to be maintained, discussed?
- If they evolve further, need there be some kind of reference implementation?
- Who drives the initiative after dissolution? Will it be all grassroots, “herding cats”?
- Or will some kind of standards-body take over? An exit strategy + handover commence?
These are some first thoughts that popped up with me this morning. I am curious as to your perspective on these matters.