New projects often started as a volunteer project with enthusiastic people. The project growed over the time and it got some or a lot of donation (or sponsor) money. That was the time, when the leading people of the project got the impression that it is not possible to drive the project with volunteers only. They decided to spend money for one or more employees. This employees in connection with the leading people of the project built a group. Both sides had an interest in keeping the project running as it is and take full control. The leading member most often had a personal or business interest in the outcome of the project. The employees had a personal interest too, because they need to pay their bills and thus need the income.
The whole group of employees and leading members had in common that they had a lot of time to work on the project. Thus they marginalized the pure volunteer contributors, because they could only work on the project in their spare time. At some point the pure volunteers realized that dominance of the other group and once they felt excluded or got no positive feedback and support for their volunteer work, they quit their contributions and left the project.
That was the time when the remaining (volunteer) member / contributors of the project complained about the insufficient number of volunteers in the project. But instead of reorganizing the project and revise its whole structure and processes, the leading group went into the same direction and replaced the missing volunteers with employees or paid work. But that didn’t solve the problems, because more pure volunteers felt not respected and considered, why they should do the work without paying.
This process will not stop until the group of leading members and employees remember that they are an important part of the issue and that the organization of the project will need a radical disruption (a new start). That includes not only the technical or organizational construction but the employed or contracted people too.
It would be necessary for a healthy new start of a volunteer project that the driving people would be able to take a look from ‘10,000 feet’ onto the project and wouldn’t be captured in the current organization and structure of the project. Thus the current leading members and employees / contractor wouldn’t be most likely the best choice to rethink and start the process of disruption. It would need a new group of active members / volunteers to drive things forward without interference of the current group of leading members and employees / contractor. The latter one had to step aside. But it most likely would need a conflict to reach such a situation.
I created a new section for documentation and howtos and added first content about LibreOffice and Plone to it. You could get there my documentation about non-code LibreOffice extensions and a howto about the development of a validation function for file extensions that could be changed by the Plone site-administrator without getting his hands dirty inside the code of a Plone add-on.
You’ll find the new section at https://amantke.de/dokumentationen-howtos/
I worked on a new Plone add-on to manage and to provide software product add-ons during the last weeks. This new add-on, named collective.addons, runs on Plone 5.2 and Python 3. It has currently a localization in German language too, but it would be easy to add further localizations to the add-on later. It needs only the creation of a subdirectory inside the locales subdirectory and a new po-file for the further language.
I created a first alpha release of the new collective.addons Plone add-on today and uploaded it to the ‘Cheeseshop’ (https://pypi.org). You can find it at: https://pypi.org/project/collective.addons/
The source code of the new Plone add-on is available at the Plone community repository at Github: https://github.com/collective/collective.addons
I created a new Plone 5.2 and Python 3.6 buildout to migrate the Plone add-on collective.clamav to this Plone version and Python 3. I had to change the ‘import Globals’ and the use of ‘Globals’ according to the information on the upgrading Plone 5.1 to 5.2 website (https://docs.plone.org/manage/upgrading/version_specific_migration/upgrade_to_52.html). I also changed the ‘implements’ statement to the ‘@implementer’ decorator.
I had to remove the backward compatibility to the AT content types. It works with the new (Dexterity) Plone content types only. I tested it successful with the Eicar virus test signatur.
I’m currently working on a new Plone add-on to manage the upload and distribution of product add-ons / extensions. I develop this add-on from scratch with my experience from other Plone add-ons which I created within a Python 2 Plone environment.
The development of the new add-on is done inside an environment of the latest Plone version (5.2) in combination with Python 3 (3.6 in this case). I started the development using Python 3 because the support for Python 2 stopps in less than five month and I thought it is not usefull to create a new add-on within an nearly outdated Python environment.
You could get the calculation of the Python 2 version retirement at pythonclock.org.
It’s time for projects using Python 2 to think about the migration to Python 3 soon.
I made a bunch of changes to the Plone add-on which drives the current LibreOffice extensions website during the last weeks. I especially made it easy to enter the file extensions for extension, image and documentation files and change them if needed. This is possible without the need of any programming skills. I had to create new validators for this purpose and replace the old ones with them.
The new release of the Plone add-on ‘tdf.templateuploadcenter’ is available via the ‘Cheeseshop’ (https://pypi.org) yet:
It is version 0.36 and you could download it from there or much easier include it into your buildout script.