Lumiera Project History

So, suddenly we found ourselves right in the middle of an exciting new movement with much drive, long debates and lots of new ideas — and, most exciting, it seemed all doable, right here and now. It should be noted however that this momentum of “new hope” was not about starting a new video editor project — we didn´t want something entirely different, we wanted a better Cinelerra. And so, throughout these discussions, it became custom to label it the-next-Cinelerra, or — as the current Version was v2.1 — just call it Cinelerra-3. Early in June 2007, Cehteh wrote a Project Manifest
[ This text has been preserved as a »Design Process« document; however, all the early RfC texts were imported into the main Git much later, in 2010 — and at that time all references to “Cinelerra” had been mass-replaced into “Lumiera”. ]
and sent a Project Announcement to the active contributors, the known Cinelerra-CV developers and Cinelerra’s original Author (“Heroine Warrior” alias “Jack Crossfire”).

Yet the most prevalent experience in those first days was a flurry of activity in various IRC channels and in endless private mail threads. The same arguments were repeated and reconfirmed over and over again. Numerous people made proposals to point out how easy this and that would become if we’d just add one special feature or use just that other technology. It all felt like flying.

There was unanimous consent that the reasons why Cinelerra got stuck were largely of social nature. If it was just easier to contribute! If just stable releases were made and improvements by the community were integrated in a less timid way, then the »community version« could gain more traction and momentum and the original author, which was perceived as a “lone wolf”, would become less important. Most participants identified with the vision of a distributed development organisation, where automated tooling helps to cross connect the people in a chaotic yet efficient way, similar to a market place of ideas, where the whole is more than the sum of its parts and overall the idea most beneficial for the community wins.

As Cehteh repeatedly put it, “the community shall be the benevolent dictator!” He had opened his personal wiki at pipapo.org to be freely editable and established a template for proposals (labelled “RfC” — Request for Comment). The very first proposal was to use a »distributed development framework« to replace all conventional project management tooling like design documents and bug trackers. There was some slight discord however if the goal should actually be a refactoring of the Cinelerra code base. Cehteh seems to have concluded earlier this year already that the code base is a “bottomless pit” and perceived it as an environment he does not want to work in. Ichthyo rather brushed that aside as “quality problems” that can be amended easily with contemporary craftsmanship. He insisted on gradually improving Cinelerra, since he deemed the application and the basic ideas of the code base to be sound and adequate to the task of professional editing, just many aspects would need some clean-up and sharpening so that the underlying ideas can be strengthened to bring them to their inherent consequence. One such consequence would be the idea of using a »Placement«,
[ The RfC entries linked here for Builder and Placement are based on HTML captures from early 2008, and were seemingly written shortly before, as the »Lumiera« project had formed officially. However, the nucleus of both ideas is already present in the vision spelled out at start of the »Cinelerra-3« movement, and both concepts were ventilated in much detail during the heated discussions of the first days. ]
which requires at least an environment at the level of maturity, as available in Cinelerra, in order to become feasible.

And while this subtle foreshadowing of contention could not be resolved, there was unanimous agreement about the first two milestones in Ichthyo's project proposal, namely to try out modern tools and to demonstrate a working technology sketch with an emulation of parts of Cinelerra’s session, but backed by the new frame cache and scheduler envisaged for the DataBackend. So a “distributed guerrilla wiki” was established, by checking a TiddlyWiki page into Git and pulling from each other. And soon thereafter, a small group of “active doers” (as Herman Robak put it) started the breeding and exchange of ideas, written down into tiny notepads called “tiddlers”, cross-linking to each other. No one could have imagined that this was the begining of a large project’s commit history.

Cehteh, always eager to experiment with technologies, proposed to try out the build systems SCons and CMake and the UML-Modeller Bouml, which all had been mentioned favourably within the community. Yet the prototype setup left him disappointed;
[ In the ensuing discussions, Cehteh opposed the idea of organising the build system as a project model, encasing the actual code like a shell — something he considered redundant and limiting; rather he insisted that a really supportive and enabling tool should “just understand the code” itself; regarding SCons he furthermore resented the use of Python, a language, which Ichthyo favoured, while Cehteh found it bloated, guided by strange principles and riddled with a superfluous and “tacked-on” object orientation. Instead, he introduced the “tried and true” Autotools, a build system, which Ichthyo and several other members of the Cinelerra community hated with passion. ]
and he also felt uncomfortable with UML. Ichthyo on the other hand, knowing UML in and out from his work job, soon happily embraced this new angle, using it as a workaround for his prototyping of Render Node generation, since Cehteh insisted not to introduce the existing Cinelerra source code yet, for this and that reason and another. Ichthyo thus quickly re-modelled the assets and part of Cinelerra’s session structure into UML, with the intention to use the code generation capabilities of Bouml to produce an extended hierarchy of class bodies and method stubs, which can then be used as a backdrop to trace out the possibilities of generating or building the Render Nodes beforehand, and not as part of the actual render invocation (as Cinelerra does). Cehteh meanwhile introduced a proposal to confine all plug-in interfaces to plain-C (not C++) — and the ensuing discussion made it blatantly clear that he furthermore intended to open up pretty much every internal part to be reconfigured and invoked as a plug-in, even allowing to bind to arbitrary other programming languages. This seemed like an elegant and obvious way to enable fluid and low-barrier code contributions, which he considered as the turning point to cure Cienelerra’s woes — while Ichthyo foresaw an explosion in complexity and was shocked by the prospect of making cohesive data-centric programming easy, while the use of the type system to express intent, and the use of those design patterns, which he associated with software craftsmanship, would become increasingly difficult and penalised up to a degree to be effectively off the table. And so this clash of cultures,
[ Sometimes people may seem to have similar political alignments, they may like each other and detect much overlap in their value systems in casual talk — but once they are working together and are engaged and entangled into all that uncanny ambivalence of reality, they end up with diametrically opposed judgement and incompatible coping strategies in response to mundane problems. The actual topic of contention seems to be more like a symptom, and the arguments exchanged seem to tap into disjoint worlds. The debate regarding plugin-centric architecture, which unfolded at this point, might be seen as this kind of an ambivalent encounter. ]
which had been lurking just below the surface, suddenly discharged into a sharp controversy regarding the idea of a plugin based architecture. Michael Ploujnikov attempted to moderate and find a compromise — in vain, as the topic appeared to be a matter of “make or break”. This quarrel thus ended without a clear resolution of the dilemma, while unfortunately also causing quite some serious loss of trust.

However, both Cehteh and Ichthyo managed to keep this strife strictly confined to the inner circle of actual code contributors and continued to uphold the facade of the project publicly. Yet this disturbance just below the surface turned out however to be instrumental for the further evolution of the movement, and the character of the emerging new code base.

After the unfriendly encounter had unfolded, Cehteh completed his work on a low-level plugin-loader and a linked-list implementation written entirely in C language. Around mid August 2007, he then directed all his work capacity towards the idea of an uWiki based on Git.
[ This effort went through several stages, starting as a web-frontend to create Git commits. Initially, during the next months, it was called »webgit«, sometime in spring 2008, the name changed to »uWiki« (‘u’ meaning µ, like in “micro”). The underlying technology for attaching to Git and for templating was also switched several times. ]
This can be seen as a direct consequence of the vision of enablement through distributed tooling. This Git-based tool was envisioned as a low-level, self-contained, rules based interpreter driven by Git commits, which could branch out into various handlers embedded into the Git repository itself. These handlers were intended to replace pretty much any known project support tooling, like bug trackers, continuous integration, release management, forums and mailing lists, documentation and wiki based website publication. Cehteh frequently pointed out that this effort was top priority, since the existing tooling is woefully inadequate and tends to discourage people from engaging in fluid contributions and thus prevents the Cinelerra-3 project to unfold its full potential.
[ This statement should be placed into the historical context: this time was the culmination of the »Blogosphere«, Github was funded in October 2007 (!), Stackoverflow in April 2008, smartphones and social networks just started to gain traction, »Pirate Parties« made significant political inroads in several European countries, with the proposal of a technology-based »liquid democracy«, while Bitcoin with its Blockchain-Technology was invented as a means to enable bottom-up financial and social collaboration through smart-contracts, which are impossible to control or suppress by central authorities. ]

Ichthyo meanwhile continued with his part of the coding work, seemingly without ever reflecting its purpose and how the structures he built might fit into the actual refactoring of Cinelerra, which all participants continued to uphold as a the goal. First he started to round out the class skeleton generated from UML and added a factory for assets and a memory management based upon the new kind of smart pointers available in the Boost libraries, which were expected to become a feature of standard C++ somewhere in the next years. And since no progress was to be expected regarding the DataBackend, the focus gradually drifted away from the Render Engine and towards the Builder, which turned out to be a problematic move. Ichthyo soon found himself entangled with insurmountable problems: it was clear from the beginning, that such a Builder, levelled up to a generic form, would lead to an internal structure similar to a language compiler: the session model would be treated as a syntax tree, to be augmented then with attributions in several passes, until it becomes possible to generate “output code” in the form of a Render Node tree.

But what structures could be expected in the session model? Those structures present in Cinelerra? are they adequate? are they sufficiently generic? Could they be mapped down and implemented by a low-level model? — which in turn was likewise thoroughly undefined, as was the implementation of actual render functionality. One of the central plans of the initiative had been to replace much of the project-specific and somewhat limited video handling code in Cinelerra with “widely used general-purpose video processing libraries” — nuff said; just, “which ones?” Many of the supporters in the community liked and promoted GStreamer, while the developers did rather not like what they saw when looking into the source code of this project: it comes with a heavy-wight framework and is more like an embedded video rendering and playback engine; and, taking a decisively different approach regarding various aspects of internal organisation, it can be expected that the GStreamer framework would rather compete for system resources with the planned DataBackend, instead of complementing each other. FFmpeg on the other hand had a reputation of being a chaotic and brittle project at that time, accumulating features without any clear vision. This was when Cehteh brought in Burkhard Plaum from the local Linux community in southwest Germany, which had written the media player and decoder framework Gmerlin, a well structured piece of software with a seemingly coherent and tidy code base. While this seemed like a good fit, several supporters in IRC rose concerns that Gmerlin might be a “one man show” — and so there would be the lurking danger that the project might end up maintaining its own multimedia framework eventually — a situation far worse than the status-quo in Cinelerra, which had just a small selection of decoders created and maintained in-project.

So all this uncertainty, together with the lack of a direct counterpart to anchor his work, led Ichthyo into a rather explorative approach, aiming at a much more generic solution, which could be used to derive, by logical reasoning, a guidance for the next steps to be implemented: he could recall some research, which he had seen back in his time at the university related to theorem proving. In such a context, given deduction rules might be related to one specific domain ontology, while facts are available within the framework of another domain ontology, so that a mapping and translation must be interspersed. When transferred to the current context, this leads to the observation that each media handling library is tightly connected to some specific formulation of a domain ontology — and this is the reason why selecting some given library as foundation has far reaching consequences and effectively locks the implementation of a render engine to that library: thereby the classification of the kinds of data to be expected, and the description how these are structured and related to each other, becomes deeply ingrained into the internal logic of the engine. Just adding another library through a plug-in would be moot; the only way to overcome this dilemma might be to conceive the engine in terms which are library agnostic. And doing so requires foremost mental work, something that can not be side-stepped by introducing technological solutions.

Meanwhile, at the outside, the »Cinelerra-3« initiative gained more and more traction. In August, in yet another thread, set off yet again by a user complaining about the current painful situation, the new initiative was hinted at and then later pointed out publicly for the first time. The word spread quickly, and the wider community started dreaming. A flood of feature ideas and well meant recommendations set in, and the wording of some ideas from half a year ago was repeated in a formulaic way, and appeared to be more convincing the more it was picked up, spread and repeated. While, on the inside, the impetus from the beginning had already transformed itself into a very narrow thread of conception work, mostly theoretical at that time, aiming for a level of genericity which was altogether unrelated to the very mundane problems, which remained unresolved and continued to make attempts of working professionally with Cinelerra a daunting task.

So the first official developer meeting on IRC was scheduled very soon, and the group confirmed all the basic traits of the initiative: a “distributed development model based on Git”, the existing setup of the source tree and build system(s), regular developer meetings every month and a semi-formal proposal process based on the »RfC« template, with a discussion on the wiki page and a formal approval or rejection by the developer meeting. Furthermore, it was decided to collectively rent a bare server in a data centre and to run our own infrastructure. By using a setup with several VServers based on libvirt, it would be possible to host several websites; notably we could offer to host the Cinelerra-CV infrastructure, thereby helping and supporting that community, which had supported the initiative and all our discussions from the beginning, and now seemed to lack the capacity to maintain its own infrastructure.

Raffa (Raffella Traniello) had noticed the important role of the wider user community, which had reinforced the formation of the initiative, riding on a wave of excitement and anticipation. She urged to look for ways to maintain a connection to the (prospective) users, providing ways to contribute with small tasks which can be handled by a non-developer. All developers wholeheartedly agreed to this vision, and came up with the idea to place the decision about a name for the new project into the hands of a community initiative, since people had started to propose lots of interesting names anyway. Raffa and Odin volunteered to look into ways to spur and then to channel such a naming discussion — which indeed carried on in a healthy way. The community continued to come up with all kinds of creative names, the first one to be proposed was, obviously, »Pr0nEdit« — and after some time, there was even some degree of convergence, with either variations of the Cinelerra name being favoured, like »CineZilla« or »Scintilla«, or ideas related to film making, like »Verite« or »cameo«, or »cutting room«. The name »Lumierra« appeared comparatively late, and was first proposed as a blend of the “*erra” template combined with the idea of “the next 100 years of pure cinema”, alluding to the Lumière brothers. Furthermore, many contributors also pointed out that the chosen name should sound “female”, like Cinelerra and the virtual Heroines. Raffa even insisted that it must be female, since females are powerful. Jay Truesdale, a producer from California and Cinelerra enthusiast, objected somewhat to this brainstorming process, pointing out that most proposed names were considered “the next Ubergeek-editing-platform” by several people he had contacted, working in the media industry. He even performed a small focus group test and found out that (to his own surprise) »CuttingRoom« scored best with 85%, while »Lumiera«, »Auteur«, »Verite«, »freecine« and »cameo« all scored in the low 40s.

The set of ~250 proposed names was then trimmed down by applying a set of rules everyone agreed to: the name should be evocative, not too limited, too funny or offensive, it should not match with an established product name and a suitable top-level internet domain should be available. This vetting process led to the preselection of 15 candiates, which were then placed into a Condorcet Voting scheme for the community to elect the winner. As a result, the new project was named »Lumiera«

And it was just wonderful being on board of this new splendid project. There were lots of tangible, practical tasks to master, promising immediate gratification. No need for endless depressing mail threads to analyse a muddled situation, no hostile »upstream«, no fighting against windmills any more, in a legacy code base where any change just ends up piling more liabilities. The tone in discussions was friendly and collaborative, there was a workable structure, and the goal of the journey was exciting and comfortably far away. Ichthyo recalls a grand sense of relieve. He somehow felt like the fifth wheel at times, since other people had the greatest say in the group — yet he was also aware of the fact that he was the only one to do actual coding work for the project, since several months already. He had built up a considerable body of code during that time, albeit most of it as placeholder code to mark out the circumference of the ideas he had developed in the accompanying conception work. But he was also increasingly concerned, as he observed that pretty much every discussion of goals within the community drifted either towards excitement about effects, the hype around node editors, a trend to create meta features like a built-in market place or collaboration platform; and the developers seemed to be excited mostly about video and GPU technology and real-time processing. The perspective of film making, of working with material to tell a story through montage, was sorely lacking. In the light of these tendencies, it seemed desirable actually to raise the bar for contributions, and to nail-in the focus towards a professional workflow, to prevent the new project from drifting into amateur territory.

However, brought about by yet another surprising turn of events, an ally appeared at the stage, to support the orientation away from mere technology and towards aspects of workflow: Joel Holdsworth joined the project as a GUI developer. He had contributed to the Inkscape project and thus brought a lot of experience with GTK, and he favoured a modern, forward looking approach for UI development: to move away from pixels and define the UI through vector-graphics and CSS layout rules rather, in order to separate style and structure, and also to employ functional closures for event handling. According to his recount, Inkscape was dominated at that time by a long-standing and tightly knit group of core developers and Joel was thus looking for a project where he could set his own standards moving forward. And thus the newly formed Lumiera project suddenly had three core developers — one responsible for each of the three layers in the planned architecture. And, even better, the decision regarding the UI toolkit had been settled without any further discussion and bikeshedding: the Lumiera UI would be based on GTK, with the intention to move to GTK-3 as soon this becomes feasible, while already relying on the C++ framework from Gtkmm and lib-SigC++ to embrace the functor-style bindings, which were expected to become part of the “C++0X” standard soon.
[ During the last months, Ichthyo had learned a lot about modern C++. He did not know the language very well previously, and had only some superficial experience with C++ in the 90ies, which had been rather unsettling. But he had worked a lot with Haskell in the past, and was happy to recognise a trend towards an object-functional fusion and a multi-paradigm language, which was present in the plans and preparation for the new language standard. Incidentally, for a short time, Cehteh and Ichthyo had even considered to experiment with the D language — but there was a quarrel and split in the D community at that time, which probably was a reason why Alexandrescu subsequently also supported the project to revive and modernise the C++ language, which eventually culminated in the ground breaking C++11 standard some years later.
During those years, several splits and ruptures could be observed in the wider developer community: some preferred dynamic languages and high-level integrated frameworks, some embraced the tendency to raise the level of abstraction and to express relations from the problem domain directly into the type system, while others moved “back to the roots” to work in a mostly data centric way again. ]

As Member of the project team, Joel Holdworth was always friendly and agreeable — a considerate and level minded man from Great Britain. But he had a clear apprehension what comprises good UI design and had a decent way to postpone all kinds of fancy UI features for later, while pulling up a new GUI framework at the same time, including considerable complexities, all in an effective way and within a short time frame. After some initial planning together with Ichthyo, where both had marked out the basics of the session interface together, it was agreed upon that the new GUI was first built as a stand-alone GUI application shell, without actual functionality. This afforded Joel to define a clean framework and lay out the foundations, without interference with the rest of the project, which, at global level, was some kind of a moving target still. Stimulated by the new coordinated activity within the project and the massive amount of code being added, Cehteh started also to contribute again, while channelling yet much further work into his uWiki vision, which he expected to yield a boost to the project, since it would facilitate casual contributions by many people. He also promised to handle bugs and project planning in the new tool, but Joel and Ichthyo indicated that they would prefer a classical bug tracker. Regarding the DataBackend, Cehteh started to provide some fundamental facilities, like a manager for file handles and filedescriptors, memory-mapping based file access and a cache relying on a MRU scheme. Michael Ploujnikov and Simeon Vökl supported him and also engaged into the development in the backend layer. Thus Lumiera had become a fast moving project with construction work happening all over the place.

more to be written as time permits…