PloneIntranet Community edition behind the scenes
Why the difference between Quaive and PloneIntranet?
22 May 2017
Some time has passed since the release of 1.0. This is mainly because of the fact that Plone software is still mainly driven by projects instead of license fees.
Plone is a true open source project and its community is a true open source community. There is no one company behind it which drives and finances the open source variant of a closed source product. This has a number of advantages. It is really free. There is a very small risk of domination of the roadmap by central control. And everybody can actually participate in driving if only he or she contributes. Of course there are more…
On the other hand, this has a number of disadvantages as well. There is the notorious lack of funds for non-technical activities. Marketing, design, planning, only to mention a few. Everything is project driven, so that if there is a project that needs a feature, it gets developed. If that feature is no longer needed, it stalls. For a long lived project, this can be hard. How can one maintain a software, fight entropy and support it over a long period of time without guaranteed funding? What if multiple organisations have begun to depend on this and it starts rotting?
Plone core has marvelously adressed this issue. For quite some time now there have been strict rules on what gets into core to limit the effort of maintenance. There is a broad consensus of what is actually maintainable and there is a great agreement on how things have to be tested. All this and more assures that Plone was, is and will stay a most stable platform to build on and will remain a safe harbor for investments.
But what about the plugin ecosystem? Everything that doesn’t make it into core becomes a plugin – published or not. Thus, quality amongst plugins varies massively. There have been attempts – like Paragon – to quantify quality and point users to the worthwhile ones, and that effort already confirms the issue at hand. It is hard to maintain plugins. Especially if the work is only project driven.
There is a good plugin hidden here. See if you can find it.
Now let’s look at the PloneIntranet project. Already years ago an open space at a Plone conference collected more than 25 add ons as requirements to build an intranet on Plone. 25 add ons with
- different quality
- different user interfaces
- different maintenance cycles
- different backend logic
- which have near endless possibilities of conflicting with each other
It becomes clear quickly that this can’t possibly work. To do this, we would need to change the approach. The challenge is to unite the best of both worlds. A plethora of add ons, working together under one roof, with a quality and foremost maintainability of something close to Plone core – with the catch that is will still be mostly project driven.
“Open Source is sustainable – building it must be sustainable, too.”
The answer to that dilemma is the PloneIntranet consortium – and a clear commitment to “dictatorship” in terms of design and quality control. This we have sustained for over three years now, and it certainly bears fruit. By putting design first in a strict manner, we can control the abundance of potential features by subjecting each one to the absolute last word of the central design. And design has the user in mind, not the programmer.
That also means that we had to commit substantial resources to this dictatorship and these resources – by law of market – need to be diverted from somewhere. We have to streamline work and attention and we have – amongst other things – done that by deciding to bulk release stable states only. While projects are ongoing, we work together in the consortium on moving PloneIntranet ahead. This works only in a confined ecosystem where the lines of communication are defined, where the call and response between developers, design and QA is frictionless. And when the projects are complete, we can pluck the fruits and push out a release.
That time has come again and we are proud that our plans on doing so actually are becoming a reality. Today we have PloneIntranet 1.1 ready, which is a stability release with a few nice features.
And we have already the next release on the roadmap, PloneIntranet 1.2 – Mars, and this is not just an idea, the code exists, and we are pushing it into stabilisation now that we have the 1.1 out. So we expect another release this year.
I have written this because there has been some confusion on why we are not working fully in the open and I hope to have explained the background for this. If you have questions about it or want to discuss it, I would gladly hear from you. Please contact us via our contact form and I will answer.
PloneIntranet 1.2 – Mars – Community Edition
Scheduled for Autumn 2017