This week I've entered the Debian NM process to move from Debian Maintainer (DM) to Debian Developer (DD).
But, what have I been doing for Debian lastly?
I've been DM for the last year, after a couple of years maintaining packages with sponsors.
Since 2015 until this time of the 2016 year, I've done roughly 33 package uploads, opened 67 bugs and contributed to many others. I maintain and co-maintain now 9 packages, most of them Netfilter-related.
This is a graph of bugs assigned to my packages in the last natural year:
I was supported to start the process by Anibal Monsalve, and Vincent Cheng intermediately become by advocate.
The duration of the NM process can vary depending on a number of factors, from a couple of months to a couple of years.
BTW, I got my opened bug statistics with this small script: deb_bugs_years.sh
Mediacurrent: Building Wunderground.com with Drupal & Angular 2: How to Bootstrap (Challenge #1)
This weekend the Skvare team attended TexasCamp, the first state-wide DrupalCamp! The Dallas conference attracted users and developers from all over the state to learn and network. Skvare showed community support with a Gold-level sponsorship. Since CiviCRM and Drupal work so well together, we shared some presentations that touched on the intersection of both.
Mark Hanna shared information on a new open-source online learning system powered by CiviCRM and Drupal. This week's release of Skvare's Tin Can compliant Learning Record Store is a Drupal-native API that expands Drupal capabilities for flexible, open-source Learning Management Software. This open-source solution can significantly lower the barrier to entry for organizations seeking to implement an online learning program.
View the video that goes with the slides below.
Feel free to play around with the alpha release of Tin Can Learning Record Store code and let us know what you think.
Kate Shaw presented an intro to CiviCRM as software for nonprofits, discussing use cases for managing membership, special events, and crowdfunding.
If you'd like to learn more about CiviCRM, now's your chance
Register to win a free ticket to CiviCon 2016 by April 15. Sessions for CiviCon 2016 are taking shape. Whether you're new to CiviCRM or a seasoned user there is something for you at CiviCon Colorado 2016! If you’re an active user of CiviCRM but lack the resources to attend, here’s one barrier that’s been removed to help get you to Fort Collins this June. Head on over to our registration page to enter the drawing!Drupal
After a long journey that lasted almost three years, the use of FreeDesktop entries is now documented in our Policy.
An as a bonus, this new version 3.9.8 of the Policy also reminds that new media types should be registered to the IANA.
Thanks to everybody who made this possible.
Jeder, der irgendwann einmal für die Sicherheit einer Website zuständig war oder ist weiss, wie schwierig und aufwendig diese Aufgabe ist. Es erscheinen fast täglich Security Updates für alle Services, welche die Website nutzt: das beginnt beim Linux Kernel, geht weiter mit dem Web Server bis hin zum Content Management System selbst, in unserem Fall Drupal.Michael Schmid Thu, 04/07/2016 - 12:36
Jedes Mal, wenn ein neues Security Update erscheint, stellt sich die unvermeidliche Frage: Muss ich nun wirklich die Zeit investieren, um das Update einzuspielen oder kann ich einfach darauf hoffen, dass ich ungeschoren davonkomme?
Bei Amazee Labs ist die Antwort absolut klar und es gibt keine Ausreden: Security Patches werden so schnell wie möglich eingespielt!
Was passieren kann, wenn jemand seinen Security-Job nicht macht sieht man sehr schön (...) am Beispiel der #PanamaPapers.
Die Wahrscheinlichkeit, dass der Leak auch technische Gründe hat, ist gross; es gibt klare Zeichen dafür, dass sich niemand um Security Patches und ähnliches gekümmert hat und dass die Site deswegen angreifbar wurde.
Bis jetzt sind keine Details bekannt, wie genau die 2.4 TB Daten geleaked sind, aber es sieht sehr danach aus, als ob eine der Websites von Mossack Fonseca, nämlich https://portal.mossfon.com, gehacked wurde.
Ein Blick auf den Source Code dieser Website zeigt, dass sie mit Drupal 7 erstellt wurde.
Wenn wir uns noch etwas weiter umsehen entdecken wir noch einige Unschönheiten.
Der Change Log zeigt auf, dass die Site immer noch auf der Drupal-Version 7.23 läuft. Das heisst, dass die Website seit mehr als 2 Jahren nicht mehr aktualisiert wurde; damit hat sie eine massive Sicherheitslücke – „Drupalgeddon“. Das bedeutet, dass man irgendwelchen PHP Code problemlos in die Site einspeisen kann.
Theoretisch wäre es möglich, dass die Site für Drupalgeddon gepatched wurde und dass nur die Versionsnummer im Changelog nicht geändert wurde. Aufgrund des generell schlechten Zustands der Site gehen wir aber nicht davon aus, dass dies der Fall ist.
Eine weitere Möglichkeit für Hacker wäre, sich Login-Daten der Site mit einer DROWN Attacke zu beschaffen. Eine DROWN Testsite zeigt, dass die Website dafür nicht geschützt war, als DROWN im Februar 2016 released wurde.
Vielleicht werden wir nie wissen, wie die Site genau angegriffen wurde, aber eines steht fest; nämlich, dass es passiert ist. Deswegen ist die wichtigste technische Erkenntnis für uns die Bestätigung, dass die Sicherheit einer Website essentiell und nicht zu vernachlässigen ist.
Genau deswegen brauchen wir bei Amazee Labs automatisierte Update Tools wie Drop Guard for Drupal und machen wöchentliche Sicherheits- und Wartungsarbeiten.
Everybody who ever had to keep a website secure knows how hard this is: Almost every day there are updates for all the different services that run your website; starting from the Linux Kernel, to the web server, and the content management system, in our case Drupal, itself.Michael Schmid Thu, 04/07/2016 - 12:35
And every time there is a new security update you ask yourself: Should I take the time and install it or can I just hope that it will not hit me, because who would hack me?
At Amazee there’s only one answer: update and fix as fast as possible!
There’s a good (well…) example of what can happen if you don’t take your security job serious these days. The #PanamaPapers are all over the media across the globe: There’s a high chance that this data leak might have a tech aspect too, as there are strong indicators that the site security wasn’t maintained and that there are several vulnerabilities.
Currently the details of how the 2.4 TB of data exactly leaked are not public yet, but it is likely that the data might have been hacked from one of the company’s websites: https://portal.mossfon.com.
Let’s take a quick look at the source code of this site; we can see that it was built with Drupal 7.
A deeper look into other files unveils more dangerous things.
The changelog shows that the Drupal version is still 7.23; this means that it’s older than 2 years and has a very bad security hole “Drupalgeddon”. This allows anybody to inject PHP code on the website.
It’s possible that the site itself is patched for this security hole and still has the version Drupal 7.23 in the changelog.txt, but from the general (bad) state of the site we assume that this is not the case.
We might never know exactly how the data leaked, but it’s sure that it happened! Our key learning on the tech side is that security is very important and laziness can have very bad consequences.
That’s why we at Amazee Labs are using automated update tools like Drop Guard for Drupal and have weekly maintenance windows for all our servers and services.
Recently the Drupal Association announced accepted sessions for DrupalCon New Orleans. While it looks like we can expect another great DrupalCon (this will be my 7th straight North American DrupalCon), one particular session on the program about the sale of Drupal modules caught my attention. Although I have tried to stay focused on preparing my own sessions, I have had conversations with other people in the Drupal community about “paid modules” that have led me to the conclusion that confusion about this topic persists. So here I would like to offer a perspective on why these kinds of plans consistently fail. Specifically, I hope to expand the scope of this frequently discussed issue and suggest why so many paid module initiatives fail: the Drupal community protects its free software with the same vigor that other communities protect artistic freedom.The GPL Protects Software Freedoms
Before offering my analysis, I should start by acknowledging the obvious reason why paid Drupal modules fail: the General Public License (GPL). The Drupal Association clearly states that “Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later.” Consequently, anyone who wishes to sell a Drupal module must provide the source code.
Drupal community members are standing by with their credit cards ready to purchase those modules – and then post the code to Drupal.org so that everyone else can use it. These principled individuals believe that copyleft provides a powerful tool for ensuring software freedom and will exercise their right guaranteed by the GPL that allows the recipient (buyer) “to copy, distribute or modify” the module or theme purchased. The seller “may not impose any further restrictions on the recipients’ exercise of the rights.” The GPL greatly curtails most plans to sell Drupal modules, and these would-be capitalists might have more success selling popsicles during a blizzard.
Yet the GPL does not close the debate on this subject. I have heard many reasons provided to justify revisiting this conversation, and most frequently they come down to money. Let me share some direct quotes used to justify the pursuit of a “Drupal Marketplace,” “paid Drupal apps,” or “paid modules”:
- “Greater usability for Drupal”
- “Lack of products is a risk to the platform”
- “Give non-technical people the opportunity to build an outstanding website using Drupal”
- Drupal should learn from “the success of WordPress” and its paid plugins
- “Quality products boost the whole platform”
- “Paid modules and distros will lead to more money for innovation in Drupal”
- “It’s a foregone conclusion that there are going to be app stores for Drupal”
- “There will be people drawn to the community who were not drawn to it before”
I have read and listened to a great deal of arguments defending these commercial endeavors, and I remain unconvinced that the potential upsides outweigh the considerable drawbacks.A History of Failure
The words of the American literary critic Fredric Jameson influence my thinking on this topic: “always historicize!” A look at attempts to sell Drupal modules reveals a distinct lack of success, and yet people continue to claim they have found a solution. Consider SubHub, who announced in 2011 to great fanfare the “World’s First Drupal-Powered App Store.” They hoped to offer some of their “apps” at no cost, while other “apps” would require a small recurring charge. This plan failed and SubHub abandoned their initiative in 2013, lamenting the fact that the Drupal community “simply didn’t share the same motivation to make Drupal a highly commercial, competitive alternative to WordPress.” My apologies to anyone who built a Drupal site with integral SubHub functionality.
Also in 2011 – a big year for “apps” in the Drupal community – Phase2 announced the Open App Standard initiative. The title contains the word “open” so surely this plan would find traction with Drupal people, right? While Phase2 found some success with OpenPublic, which uses apps, I don’t see evidence that “apps” ever found traction in the Drupal community, and certainly not adoption with alacrity.
Keep in mind that many people make money selling Drupal services and that the community generally supports such efforts. I work at a company filled with people who make money building Drupal websites. Rather, I think this evidence shows that paid module schemes tend to fail, that others have found Drupal to be “actually a horrible solution to build apps,” and that when people ask the question, “Is a Drupal App Store a good idea?” the community generally responds with a decisive “no” (unless it features ponies). We absolutely want people to succeed in the community, just not by selling modules.
Certainly exceptions exist. For instance, some companies have found success selling Drupal themes. A case could be made that Acquia, a company founded by Drupal’s creator, peddles its own variety of “paid apps.” The Acquia Connector module “enhances the Drupal experience by providing the support and network services to operate a trouble-free Drupal website.” However, the module does little without an Acquia Subscription, which requires regular payments.
Acquia, and other similar services, get around the restrictions of the GPL by taking advantage of something known as the “application service provider (ASP) loophole.” When the Free Software Foundation published GPL version 2 (all Drupal code must be GPL version 2 or later) in 1991 we did not use web services like we do today. Because providing a subscription service (such as Mollom or New Relic) does not involve distributing software, Acquia need not provide any additional code than that which connects the site to the service.
The Drupal community could adopt a stronger copyleft license that closes the ASP loophole, such as the Affero General Public License (AGPL). Just do not expect this to happen anytime soon. Dries Buytaert, the founder and project lead of Drupal, built a business that takes advantage of this loophole and he made his opinion clear a decade ago in a blog post titled, “Long Live the Web Services Loophole.”
Consequently, the focus of the discussion around paid modules often revolves more around the merits and problems of what Richard Stallman calls “Service as a Software Substitute (SaaSS)” than on actually selling Drupal modules that address common challenges. While some companies have found success with the SaaSS model, why do so many others fail? To answer this question, we must look beyond code and licenses to the Drupal community.Products and Practices
I wrote at length about the Drupal community in previous articles such as “The Cultural Construction of Drupal” and “Better, then Bigger: Cultivating the Drupal Community,” and I do not intend to re-hash those same ideas here. Rather, I would like to examine why “paid module” schemes have flopped.
As I see it, one fundamental explanation for failure has to do with when business people misunderstand Drupal as a product rather than an organic accumulation of practices, or more broadly, when they ignore the differences between machines and humans. I deliberately add the qualifier “business” to describe these people because all efforts to create paid products are intended to generate revenue. Efforts to sell Drupal modules, in the Marxist sense, epitomize efforts to create capital, to accumulate money – a goal that comes off as at odds with a community that values participation.
All modules that come with a fee are intended to generate revenue, but we must not forget that “free” modules (that are also “Free”) have the potential to do the same. Many people, including me, enjoy getting paid to write Drupal code. For the paid module argument to work, its defendant must demonstrate that existing models are somehow lacking. Defending a new commercial approach necessitates, in my view, demonstrating the unsatisfactory nature of a free software project with more than 33,000+ shared modules that has existed for more than 15 years and has a vibrant marketplace of vendors offering Drupal services. Such an argument not only requires a high level of mental gymnastics, it, at least tacitly, represents an affront to years of successful collaboration.
Because some of those recommending that Drupal re-evaluate its commercial ecosystem are contributing members of the community, I open myself up to the critique of constructing inaccurate divisions, pitting Drupal and its community against business people who desire to convert Drupal into a revenue-generating product. But we know too well that many of us in the Drupal community could represent either side. We aim to balance our need to support our families with our desire to defend Drupal and fight for its freedom. Luckily, we can often choose both.Drupal as Art
Moving away from discussions of licenses and capitalist motives, I would now like to venture beyond the typical boundaries of the “paid module” discussion to explore why people feel so connected to Drupal. I get the sense that many people in the Drupal community do not actually understand the intricacies of the GPL and how it differs from other free software licenses such as the AGPL. I believe that the community is protecting something more ephemeral. Consequently, this part of my argument ventures into much more abstract topics and requires thinking about Drupal differently, less as a “technology” and more as an artistic practice.
I am not the first person to notice Drupal’s artistic side. For example, a DrupalCon session had the title “Zen and the Art of Drupal.” Someone else even created a new word, “Drupl’Art,” to describe “Drupal code that is both beautiful and artistic.” The conception of “Drupal as art” is not new, but I am going to be using it here in order to offer new insights into how the Drupal community works.
More than just a thought experiment, the idea of Drupal as art becomes useful when we position it within another long-running debate, namely the effect of technology on art. For instance, when proponents position technological advances as something that improves the lives of many, critics will sometimes note that those advances also threaten the purity of art – for example, photographs (the “new technology”) were seen as a threat to portraiture (“pure art”). Ironically, Drupal, as I construct it here plays the role of art, even as we cannot deny that most people would label Drupal “technology” well before they would ever call it “art.” And yet when members of the Drupal community react negatively to the suggestion of paid modules, it is not simply because of the GPL, it is because the community is defending its perceived “purity.”
Drupal and art have both been understood as pure expressions, deeply tied to their predecessors, consisting of ever changing practices, and driven by community. Yet it would be idle to suggest that concerns about the threat of technology to art are exactly the same as concerns about the effect of paid modules on Drupal’s ecosystem. Nonetheless, I believe that we can better understand the Drupal community’s typical allergic reaction to “paid modules” by interrogating previous debates about technology and art.
This line of reasoning follows a long history of thinkers who have conflated art and technology that goes at least as far back as Ancient Greece. The Greeks did not enjoy art for aesthetic reasons. The word “technology” refers to a “treatise on a practical art or craft” and its Greek root is techne. For the Greeks, techne also referred to art. Aristotle described techne as both practical knowledge and practical art. And what Drupal enthusiast would not admit that most websites convey practical knowledge?
In his 1954 essay, “The Question Concerning Technology,” the German philosopher Martin Heidegger variously described both art and technology as a “mode of revealing,” a way of “bringing forth.” A painting reveals another person’s point-of-view and a website “reveals” information. As uncomfortable as it may seem to some among us to describe Drupal as art, it helps explain why people feel so connected to Drupal and vigorously defend its purity. The community wants to work together and reveal its solutions rather than hide them behind a web service. Developers treasure not just revealing websites, but revealing (sharing) the code in the modules that enables their functionality.
Another well-regarded German philosopher, Walter Benjamin, provided valuable insights that are useful for our purposes in his 1936 essay, “The Work of Art in the Age of Its Technological Reproducibility.” Therein Benjamin explores when inventions such as photography and film (both being kinds of “mechanical reproduction”) “separated art from its basis in cult, the semblance of its autonomy disappeared forever.” Not only did these products threaten the group, they also threatened the group’s output (its art). He believed that “the unique value of the ‘authentic’ work of art always has its basis in ritual.” Likewise in the Drupal community we value ritual: we discuss issues, post patches, review the work of others, attend camps and cons, celebrate the accomplishments of new members, and create code with unique value – code that lives with other Drupal code on Drupal.org. Hiding code threatens our rituals.
Paid modules or services revoke our access, our autonomy, and our beloved practices. Drupal is something people do, and we cannot learn by doing when we cannot see the code. Products are purchased, while practices are lived. Drupal, like other forms of techne, is communication, and we cannot communicate in the same manners with black boxes as we can in the issue queue.
In addition to affecting what we do, the existence of paid modules could negatively affect perceptions of the Drupal community. Benjamin writes of a “decay of the aura,” which sounds much like what the Drupal community works against. While some may argue, as one Slate writer did, simply that “Drupal hates change,” many in the Drupal community still believe that Drupal exudes a sort of magical aura. We hold the community close to our hearts and defend its name. We do not half-heartedly promote our community, we instead speak of our “unique, diverse Drupal community,” say that “Drupal has made a big difference in my life,” and that “I’m truly proud to be part of this community.” We protect our people, practices, and reputation by following the Drupal Code of Conduct, in the hope that “we preserve the things that got us here.”
Our current system for creating modules on Drupal.org values the work of humans. Benjamin observes, “What matters is the way the orientation and aims of that technology differ from those of ours. Whereas the former made the maximum possible use of human beings, the latter reduces their use to the minimum.” Drupal is not so much the thing that is built but the way it is built by people. In fact, one of Lullabot’s most frequently quoted core values is “be human.”
The Drupal software will never be complete, and we hope the sharing continues indefinitely. In the same spirit, Benjamin believes, “It has always been one of the primary tasks of art to create a demand whose hour of full satisfaction has not yet come.” The Drupal community wants to continue building, to keep moving forward, never content that we have finally arrived at an “end” where our interactions have been replaced by web services.
Fredric Jameson once warned that “machines are indeed machines of reproduction rather than of production.” The Drupal community has produced a great deal of code that powers much of the web. Few among us would want to shift from production to reproduction, from working together to solve problems to purchasing solutions to problems. Repeatedly and continuously solving the sames problems – building the same websites – breeds boredom. We like to create new and shiny things, producing not reproducing. Our rituals, our process, and our freedom to tinker allows us to continuously move forward.The Contrasting Case of WordPress
Even if these theories accurately describe the Drupal community, they do not fully account for the success of paid WordPress plugins. Do paid plugins make WordPress unpure, inhabited by a community of dispassionate contributors? Absolutely not. Does the availability of paid plugins somehow cheapen the WordPress community or imply that WordPress lacks meaningful rituals? Certainly no. WordPress powers a huge chunk of the web with GPL-licensed code. It would be fruitless to deny the overwhelming success of a project with a vibrant community. Rather, I hope to convey how the WordPress community’s embrace of paid plugins informs my argument that the Drupal community understands its practices as a kind of artistic expression.
Simply suggesting that WordPress and Drupal are different helps about as much as arguing that Drupal and WordPress are words that contain an incommensurable number of letters. We could go a step further, as Dries Buytaert often does and argue not only are they different, but that WordPress and Drupal target different markets, with “WordPress dominating the small business segment” and Drupal geared toward the “larger organizations with more complex requirements” (an idea I dispute). If that were true, one would think the community that caters to “large organizations” would have the customers with the funds to purchase modules rather than get them at no cost. Then again, the reverse argument seems equally defensible, and that small businesses would rather pay for plugins than for those reportedly expensive Drupal developers. None of these avenues feel satisfactory.
One might expect that WordPress and Drupal espouse contrasting ideas about paid add-ons and the GPL. Quite the contrary, the Wordpress.org licensing page provides clear guidance about how plugins should be licensed: “derivatives of WordPress,” including plugins and themes, “inherit the GPL license.” While they admit to “some legal grey area regarding what is considered a derivative work,” they “feel strongly that plugins and themes are derivative work and thus inherit the GPL license.” The community leaders back up their assertions with thoughtful discussion as well as expert analysis from the Software Freedom Law Center. The WordPress licensing page even provides a link to Drupal’s “excellent page on licensing as it applies to themes and modules (their word for plugins).” Thus, WordPress and Drupal provide almost exactly the same guidelines.
Remarkably, certain members of the WordPress community completely ignore the advice on the licensing page. They claim “the GPL FAQ has no legal validity.” Some sellers proudly declare, “got my own licensing terms” and others offer code with terms and conditions that make no mention of the GPL. Some explain the norm thusly: “Premium WordPress plugin and theme developers usually sell you a license key, which allows you access to support and automatic upgrades.” One store believes it takes advantage of GPL loopholes and sells plugins under a default split license ostensibly to “protect authors.” In other words, the WordPress.org plugin directory that lists over 40,000 plugins is not a comprehensive directory of WordPress plugins. If this sounds a bit like the Wild West, then you may be a Drupal developer.
If Drupal modules are about process, then WordPress plugins – at least a portion of them – are products. Members of the WordPress community write at length about the benefits of "premium products." Some stores offer plugins that are “guaranteed to work, always updated, top quality plugins. Beautifully coded, packed with features, and easy to use.” They offer “free trials.” Another store proudly trumpets its “professionally developed and supported options not found on WordPress.org.” Ventures of this nature are justified with such syllogisms as “‘free’ doesn’t make me rich.” Plugins like these are products, plain and simple, and clearly the WordPress community (“happy customers,” as one site put it) willingly pays.
In comparison, Drupal developers get modules from Drupal.org. More than just a “best practice,” this is the norm in the Drupal community. It keeps things simple, and has a practical benefit: acquiring a new module requires typing drush dl module-name.
Incidentally, another kind of software facilitates an analogous workflow: GNU/Linux. For example, to install software on my operating system, Debian, I type apt install package_name. I would never consider downloading software to my computer from some random website, let alone software that I could not inspect. For me, at least, these two processes (drush dl and apt get) feel nearly identical, and I could make a good argument that the Drupal community is more like the Debian community (i.e., that many of the commitments outlined the Debian Social Contract are lived in the Drupal community) than the WordPress community.
Once again, the words of Benjamin feel relevant: “It might be stated as a general formula that the technology of reproduction detaches the reproduced object from the sphere of tradition. By replicating the work many times over, it substitutes a mass existence for a unique existence.” App stores for paid plugins fragment traditions established on WordPress.org. The Drupal community, on the other hand, has decided not to purchase paid Drupal modules, not to depart from its tradition of keeping Drupal as close to 100% free as possible. Whenever this issue arises, the Drupal community votes with its voices and its wallets to favor practices over products, to reveal the modules it creates rather than conceal them behind paywalls, to work with – rather than sell to – each other. The fact that WordPress customers have chosen a different path reveals contrasting, not misplaced, priorities.
While it is difficult to generalize a community with more than a million users (or at least user accounts), Holly Ross, Executive Director of the Drupal Association, believes “the one thing we all have in common is that we care about the fate of Drupal.” It might be fate that someday paid modules will find success in the Drupal community, and that would not necessarily be wrong. It would mean, however that the essence of Drupal has changed. That may even signal the end of Drupal. But history suggests that day will not soon come. Until then, the Drupal community will continue to defend its practices. It will band together to resist paid module schemes, treat its software with a reverence that others reserve for works of art, share code, and encourage others to do the same.
Benjamin, Walter. The Work of Art in the Age of Its Technological Reproducibility, and Other Writings on Media. Edited by Michael W. Jennings, Brigid Doherty, and Thomas Y. Levin. Cambridge, Mass: Belknap Press, 2008.
Heidegger, Martin. The Question Concerning Technology and Other Essays. New York: Harper Perennial, 1977.
Jameson, Fredric. The Political Unconscious: Narrative as a Socially Symbolic Act. Cornell University Press, 1982.
Jameson, Fredric. Postmodernism, or, The Cultural Logic of Late Capitalism. Duke University Press, 1992.
So far, 2016 has been a great year for Drupal and Drupalize.Me. We started off as our own company, and we’ve been heads-down on lots of new Drupal 8 tutorials. We have a deep love for Drupal and the community around here—so in addition to working hard at our business, we encourage each other to roll up our sleeves in the wider community as well. Here’s a little rundown of what’s been on our team’s radar recently.
Recently, I have been working on a site which has a big mutli-step form which is using a lot of custom form elements, custom auto-completes, custom form api states and ajax based sub-forms. It is all built using Drupal form api. The best thing about this form is that all the fields and sub-forms map to a data model. This gives us the benefit of validating the form fields using the Symfony validation component. This is good because we can write all the validation separately and test it using phpunit without bootstrapping Drupal. To convert this data model into form fields we wrote a form factory and connected it all together using the service container module.
Whenever you are working with complex multistep forms and updating a sub-form based on user input then you can't exactly show the form errors in the order in which the fields appeared on the form. In this post I'll explain a process in which we can achieve just that - keeping the form error messages in the same order as the form fields.
I've just released version 1.2.0 of Nageru, my live video mixer. The main new feature is support for Blackmagic's PCI (and Thunderbolt) series of cards through their driver (in addition to the preexisting support for their USB3 cards, through my own free one), but the release is really much more than that.
In particular, 1.2.0 has a lot of those small tweaks that takes it just to that point where it starts feeling like software I can use and trust myself. Of course, there are still tons of rough edges (and probably also bad bugs I didn't know about), but in a sense, it's the first real 1.x release. There's not one single thing I can point to—it's more the sum.
To that end, I will be using it at Solskogen this summer to run what's most likely the world's first variable-framerate demoparty stream, with the stream nominally in 720p60 but dropping to 720p50 during the oldschool compos to avoid icky conversions on the way, given that almost all oldschool machines are PAL. (Of course, your player needs to handle it properly to get perfect 50 Hz playback, too :-) Most likely through G-SYNC or similar, unless you actually have a CRT you can set to 50 Hz.)