Aligning GSoC Projects with Plone’s Architectural Principles

Development Developing for Plone
, ,
1

Full disclosure, the phrasing below comes from interacting with ChatGPT. Full conversation in the link at the bottom.

I just watched Daniel Nabil’s PloneConf 2024 presentation on his GSoC project, which integrates Google Gemini Flash to generate alt text for images in Volto. The project is interesting and addresses a real accessibility need. However, it also raises a broader question: how do we ensure that GSoC projects align with Plone’s core architectural principles?

Daniel’s implementation hooks into Plone-Volto and modifies the image block UI to add title and alt attributes during upload (code here). While this works for Volto users, it bypasses Plone’s Python-based core and doesn’t integrate with content behaviors, which are the standard way to add metadata (extend content types) in Plone. This means Classic UI and API users don’t benefit from the feature, and it sets a precedent for frontend-only solutions that could fragment functionality in the future.

A better approach would be to follow an architectural pattern similar to how we integrate external services in Plone.

  1. Backend-first API integration:
  • A REST client (e.g., requests) is initialized in Plone to communicate with Google Gemini, handling authentication (OAuth) and requests.
  • This ensures Plone, not just Volto, can access and process AI-generated metadata.
  1. Presentation via viewlets and behaviors:
  • This could be done via a REST API connector, a viewlet queries the API and displays the response in a ZPT template within a theming/policy package.
  • For Gemini, a similar approach could store AI-generated attributes in Plone’s Dublin Core metadata via behaviors.
  1. Zope event hooks for persistence:
  • If AI-generated metadata needs to be stored permanently, it can be hooked into Zope’s event machinery, ensuring that descriptions are saved with the image object.
  1. Volto as a pure presentation layer:
  • Since "Image" is a standard Plone content type, Volto would not need any customizations—the backend would already provide the enriched metadata via REST API.

By structuring the project this way, we get a unified Plone-wide feature rather than one that only works in Volto.

This brings me to the bigger question: Should we establish guidelines to ensure GSoC projects follow Plone’s architectural principles? Some ideas:

  1. Backend-first design: New functionality should integrate with Plone’s core rather than being Volto-only.
  2. Extensibility via behaviors: Features should be Plone-native, not hardcoded UI modifications.
  3. Long-term maintainability: Plone’s APIs should be the primary access point, so functionality remains accessible to all frontends.

Thoughts?

Norbert

3 Likes
2

I don’t think we have yet had this kind of analysis of GSoC project architecture before!

Given the relatively short time frame, many GSoC projects are necessarily more of a technology demonstration or prototype, rather than a focused and refined finished product. It would be the responsibility of the mentors to help the students deliver the “best” end product possible. And, even before that, there is a long period during which proposed ideas can be refined and checklists can be applied.

It could be that a project requires further work for it to become a production ready deliverable. Perhaps a second GSoC project that builds on the results of the first?

And of course “best” is interpretable…and there is only so much a student can be expected to master in terms of all the technologies required.

In some ways, Volto is going to be much simpler for a newcomer to understand and master than everything required to build a back end product. Many students nowadays are familiar with React and REST APIs.

3

My own words this time :wink:

Hey @tkimnguyen I agree with you that it is nice to show "Yes! Plone can do this too!" - features that are achievable without deep understanding of Plone as a framework.

In the video, note the questions that @polyester asked at the end of the presentation. You have worked on autofocusing images, there is a useful imagecropping feature, now we can add titles and description in a new cool way... But what if someone wants to combine those handy tools together? Difficult!

I believe that we have a need as a community (Foundation?) to steer development in an organized fashion (i.e. what @davisagli proposed in his video regarding websockets support, or how the Volto team is limiting new Github PR's). Maybe GSoC could be framed as the prototyping playground that results in ideas that can be fleshed out in future PLIPs - without a promise of actual direct implementation.

To me GSoC seems to be a great marketing tool/platform for attracting new young developers who are just cutting their teeth on MERN stacks and hopefully also other technologies. I think it is awesome to see an influx of fresh energy in our community, but maybe we can help prevent them burning out quickly after finding out that "there is more to Plone" than creating a new theme or overriding a Volto block.

Not sure if I am explaining myself clearly here... It's just that I think that in the long term (next 25 years?) it is in the best interest of the community to invest in success stories like GSoC and Daniel's project. The long term value could be improved by adopting a more structured approach. Having had no direct GSoC involvement myself, maybe I am basing my opinion on the wrong assumptions and people like @ebrehault can set me straight.

Norbert

1 Like
4

It sounds to me like we have a new volunteer mentor! :slight_smile:

1 Like
5

and this sounds like a good project idea that you should post in Project ideas for GSoC 2025

...and that you should volunteer to mentor! :smiley:

6

I would disagree that GSoC should be limited to this. We have had many successful GSoC deliverables that were ready to deploy into production!

What we end up with in each case will depend on many factors, including the student's abilities, time commitments of the student and of the mentors, the idea that was proposed, refined, and submitted.

7

GSoC has been wonderful for Plone (and for the students!) in so many ways, and we continue to invest in the program and in the students... for example our commitment to inviting successful students to the following conference. I understand this is something that very few projects do, and may be one reason why we have been favoured by the GSoC gods and continue to be awarded projects...

I'm not sure there is burnout in GSoC students, but perhaps we should reach out to them and ask!

From what I've seen, most students do not continue their involvement in Plone, for various reasons, but usually that they find employment that does not require the use of Plone. Some of them deliver their project but do not seem that engaged. I have seen students get full time jobs (not in Plone) part way through their project and have a tough time completing their project.

On the other hand, on occasion we get star students who not only do an amazing job of delivering a fantastic finished product, they get hired on by Plone companies or become Plone integrators themselves ...and eventually mentor and hire more GSoC students (you know whom I'm looking at! :sunglasses:)

I think it takes years of hard effort before someone can reasonably be excused for "burnout".

1 Like
8

I will take a deeper look... May be more doable than rejoining the Marketing team in terms of time constraints.

Regarding burnout of fresh "Plonistas", maybe also distracted by other life/career events, changing interests. But I would not underestimate "Plone is difficult and complicated" as a factor.

I admit that I have been too deep into my own Plone projects to closely follow new developments in general. Could well be that mentoring a GSoC student would provide new inspiration. No promises yet though.

9

Hi Norbert,

I'm thrilled to receive new insights into my project and to learn about the architectural principles that can make it more useful, and if it was not interesting I wouldn't get a new enhancements for it so thank you.

As Kim mentioned last year, when I first started contributing to Plone, it was challenging to grasp all this information. I wasn't deeply familiar with Plone; I discovered the project while browsing organizations on the GSoC website and found one that matched my experience, but you guys you have experience with Plone for years :star_struck:

My initial solution was to implement the feature in Volto to make it functional, especially since my project was categorized as small. I focused on creating a working PoC rather than strictly adhering to the architecture. Although I proposed in my proposal a solution using REST APIs and implementing it through the backend, I found it quite difficult at that time while trying to navigate through it to formulate my proposal I found a working solution while trying to do it in Volto and put it also in my proposal.

Now, with some experience in Plone, I understand your perspective and appreciate the feedback. I'm eager to refine the project for production use and consider integrating the additional features Paul mentioned. However, I believe I would need a mentor to guide me through this process, as I don't feel confident contributing to this add-on independently. If anyone is interested, we could propose this as an idea for GSoC 2025. I would be delighted to work on it again, especially since I plan to contribute to Plone with a larger project this year through GSoC 2025.

5 Likes
10

And a very useful PoC at that, thank you!

Yes, there are many moving interrelated parts in Plone. As I wrote above, I still find it a challenge to stay familiar with everything that goes on in terms of architecture and the general direction Plone itself is taking.

You only have to look at the first page of this forum to see that there is a lot of movement: from CI, to testing, to refactoring of packages, even setup methods on different OS and CPU.

I sat down a few hours yesterday to familiarize myself with GSoC from a mentor perspective, and am still digesting that information. Needless to say: I learned a lot.

As you say, a small GSoC project is quite well suited to create "a working PoC rather than strictly adhering to the architecture." or as Kim calls it: more of a technology demonstration or prototype, rather than a focused and refined finished product.

Yes to that too... I could see a small GSoC project being used to polish (parts of the) the administrative backend or to tackle operational inconsistencies between various Plone components, or to address low-hanging fruit like "changing the logo". These types of projects would be expected to have production-ready deliverables - and be announced as such...

Medium and Large GSoC projects could then be structured in a more PLIP-like fashion, and have the student become part of an experienced team that is already deep into the subject matter.

In those cases, the student would focus on applying their specific technical skills: be it MERN-stack, Python, AI, CI, deployment tools, etc. in a more-or-less directed way by the other team members and become vested in something that is larger than what they could have achieved alone. This provides context to the student as a participant -- also for the long term, and directly integrates the GSoC project into something of value to the whole community.

By inviting GSoC students to the Plone Conference the Foundation has already identified, and clearly acknowledges, the strategic value that we receive from summer of code projects. Does anything stand in the way of further aligning these projects with our architectural principles and being deliberate in terms of steering GSoC resources toward our own priorities?

2 Likes
11

I can think of three things.

  • Lack of experience required to follow, much less understand, Plone's architectural principles by GSoC participants.
  • Lack of time from qualified mentors to guide GSoC participants.
  • People who have experience with Plone's architectural principles are focused on delivering Plone 7.

A GSoC project might be a task within the Plone 7 roadmap, but the mentoring process pulls the limited number of developers away from Plone 7 development, delaying its release. GSoC projects and Plone's roadmap rarely align. They're too different across timelines, requirements, experience, and knowledge.

1 Like
12

Valid points for further discussion, thanks @stevepiercy

From the lack of traction that this thread is getting so far, I suspect that my timing is wrong. I can think of other arguments, and also counter-arguments to knowledge-gaps, lack of time, motivation or resource drain.

Hope we can pick up the discussion and make it more productive sometime in the future, maybe after GSoC or Plone 7 launch.

Norbert