Published on March 3, 2017 by Christopher Zimmermann
We just published a standard on how to share light modules on npm, as well as a step-by-step guide, example modules, and a chat room to get help with sharing. Oh right, and a component sharing contest till the 31st of March to spice things up a bit.
What's it all about? What's the big idea?
Wouldn't it be great if there was a big collection of Magnolia templating components on the web? If you, or your dev team, could find a ready-to-use map, or social widget, or charting component, rather than always needing to build everything from scratch?
We've had many great modules contributed as open source by the Magnolia community over the years. Thank you for those! With light modules, I saw the opportunity to spark a new wave of contribution. Github (and package managers like npm) have ushered in a new golden age of social-network-effect sharing and collaborating. Light modules are a good vehicle for sharing because they are simple and transparent. As a developer, it can be hard to evaluate and use a 3rd party module, whatever the technology, because it can do so much to your system. A light module is easier to evaluate since its scope is more limited. And a module delivering just a single component is even easier to understand - and to create.
OK, but who's going to do the work? I hear someone asking: "Why should I bust my butt for all y'all? I did all this work, spent all this time (or I paid my developer hard cold cash to create this component.) Why should everyone else get a free ride? My competitors might even use it!"
Why open-source code? A quick recap of what I presented in the webinar yesterday:
First of all, it just feels nice to share. It's like cooking a meal - I need to cook for myself anyway. But while I'm at it, it's more fun if I can share it with family and friends. I'm happy that other people are enjoying, or getting some benefit from what I've created.
If I cook for you sometimes, you're probably going to want to cook for me too. This is how communities grow. Yes, you might help competing partners, but from another perspective - as we see at the partner days and Magnolia events - we're all in this together. We all stand to gain, the richer the Magnoila ecosystem becomes. Magnolia becomes more visible in the CMS / DXP space, and more attractive to evaluators and in RFPs.
All right, "sharing is caring" moments aside (wipes tear from eye), there's the more tangible benefits: people will find and report bugs in your code, they might even submit fixes and improvements or translations (yes, this is really happening all the time on github.) And your company will gain visibility.
One of the coolest things for us developers is that we all get to see how others are working, and pick up new ideas and practices. This is a key factor in the rapid innovation these days in software.
Here's a video of the webinar on component sharing. The beginning covers the "why share?" topic.
You can jump straight to a live demo of how to share a component at 21m:57s.
Ever since we started considering light modules back in 2014, I've been fascinated by one possibility it provided: encapsulating everything for a component in a small, easy to understand package. At the time, we were experiencing some of the disadvantages of a tightly integrated set of templates. Meanwhile, the web component spec was getting its first round of buzz, and I heard about some partners that were even wrapping each of their components in individual maven modules.
In response to our developer interviews and surveys, there were a few inspired comments about using Bower or npm to share components (from Marvin Kerkhoff, and one other - I searched the wiki and my mail but could not find it. dang.) So then in the 2015 conference, when we launched light development I proposed an unconference session on sharing components and was overwhelmed by how many people attended and were interested in (and skeptical of) the topic. A great session - including suggestions of a centralized repository for sharing them, and a competition.
At any rate, after launching the new slim and svelte MTK, there have been occasional requests to provide more component templates. We've debated that internally, but stuck to the original vision which is to provide just the core components with html markup to interface with Magnoila - and not to cross the line into specific CSS and JS frameworks. Other components could be delivered, but not as a part of the MTK. For me the most important reasons are to keep the MTK templates from becoming outdated, and to ensure that front-end developers have nothing in the way and complete freedom to "do their thing". In one of those recent conversations, Jan (our CTO) suggested, "why not do a competition?"
Since 2014 a lot has changed; component-based design has supplanted MVC / MV* to become the leading pattern in UX and JS frameworks (Pattern Lab, BEM, Angular, React & friends). Which also raises exciting ideas about the cross-over of JS frameworks and CMS. I'm looking forwards to exploring this further, and welcome your thoughts on the topic.
So, what are you waiting for? :D
Checkout the contest page - and the prize: http://mgnl.io/ld-opensource
Let's get cooking!
(Lead image "matsutomiya kotobuki ichie" by George Arriola)
See all posts on Christopher Zimmermann