Hi Andreas
your reply showed little up to no knowledge and interest in that
CMS/DMS.
That's quite right. I'm really not interested in CMS/DMS (at least here) but in a sound and sustainable solution which eases the work of the MC. You may convince me any time, but I'm rather suspicious with proposals containing statements like "probably" or "90%"
Why should I bother /nudge Plone developers and ask them to spent
time on a proposal? Your response shows a very hostile tone towards
the Plone open source community. ... (and for the records: I'm not a
Plone developer, but developed Plone add-ons)
And yes, I'm (here) not interested in the plone community. That's not the point at all: Here at TDf we're interested in LO and some related fields. That's our "core business" if you want. The necessary rest gets more or less outsourced if we can afford it. No one would expect TDF engages in i.e Gnucash community just to get it's bookkeeping managed. We instead would pay a gnucash ecosystem company to do the necessary coding, thus following our own credo on how open source software of a certain complexity can be sustainably supported.
So we look for a company to outsource a special problem solution, described in the specification document. And we are willing to pay those ecosystem companies for services we feel in need of but which we don't see as our core business (we strongly prefer companies engaged in open source community). i.e. a company which does the necessary plone adjustments. But we surely not would ask the plone community or a certain developer to do so on a voluntary base (c.f. "credo" above).
Maybe you have not been part of the crew that worked on the first
steps of the project and it's infrastructure. If individuals or small
groups wouldn't have set up a website based on Silverstripe (without
asking for permissions or without a poll) or a Template and Extension
website based on Plone, maybe the project would discuss have
discussed about this tooling for month without any visible action.
Right, it happened that I was in Nepal at the time TDF was founded
And all of this was surely true and necessary at the very start of the project when we didn't have the resources for other/better solutions.
One core principle of the project is that the doers decide the way
and you'll find this form of action at many places in the project.
This principle will fail (for a volunteer project) once the people
that want to tell the doers what and how they had to work, becomes
the majority or the bosses.
All right for the mentioned "core business" - or in other words: the goals of the foundation following our statutes. That's how a community works we believe. Besides: LO in no way is or ever was "volunteer project" (a project has a start and an end). It's a community with a high extent of volunteer engagement.
But this is in no way right if it comes to administrative decisions. To stay in the above example: It sounds rather silly to start a community wide discussion on which software we will use to do our bookkeeping. And in our case, the MC is "the doers". The tooling we use until today emerged exactly the way you described above: Someone set up something which was far way better than nothing. But it has some severe immanent drawbacks. And we understood that we don't have the skills to set up a solution by our own which satisfies our needs.
So we made a tender on this. Anyone who offers a sound solution is welcome. Within the boundaries of the specification and some abstract requirements like acceptable bus factor or serviceability.