The OpenShot video-editor project recently released builds from the long-awaited 2.0 series. Although they are still tagged as "betas," they offer a glimpse at what the development team has been up to since its previous stable update in late 2012. Many fans of OpenShot have learned to be patient, but the 2.0 is worth a look even for those with no prior experience.

The first beta release was announced on January 16, with binary builds provided only to the project's Kickstarter supporters (source code, of course, was available in the repositories). In February, the third beta (version 2.0.6) was made available to the public. Linux, Windows, and Mac OS X binaries are available for download, as are source code bundles.

The previous stable release was version 1.4.3 from October 2012. At that time, plans for 2.0 were already in discussion, and there were some overly optimistic estimates for when it might be released. The lengthy delay was the result of lead developer Jonathan Thomas's decision at that time to stop and rewrite nearly the entire application. OpenShot 2.0 is built on top of a new video-editing library (libopenshot) developed in-house to replace the Media Lovin' Toolkit (MLT) library used in the 1.x releases. In addition, 2.0 drops GTK+ for a completely rewritten PyQt5 user interface, and adds support for both Mac and Windows machines.

Considering the scope of the work involved, the repeatedly pushed-back release date for the 2.0 series is not surprising. In March 2013, Thomas ran a successful Kickstarter campaign to fund his own development time (predicting a December 2013 release date). Despite the slipping schedule, though, he has regularly posted progress updates about libopenshot and the application—no doubt contributing to the continued goodwill that the user community still expresses toward the project in forum posts and comments on the blog.

With the new beta releases, that community can finally put the new codebase to the test—and, because the 2.0 builds include all of the editing and export features found in 1.x (plus a few additions), users can try out the new release on projects similar in scope to those handled by the old OpenShot.

Users coming from other video editors will find the basic interface familiar enough to get started right away with little need for introduction. The main window provides an editing timeline where users can add video and audio tracks, a video player for previewing edits, and a tabbed browser that provides quick access to imported video clips, effects, and transitions. Clips are added to the timeline with drag-and-drop, and most of the additional tools for manipulating a clip are found in the right-click context menu. This includes fade-in and fade-out settings, audio volume, rotation, and even the "split" tool used to cut a clip into segments.

In fact, so many tools and settings have been moved into the context menu that users might be alarmed when they cannot find buttons or menu items for the features they need. In previous releases, for example, several of these settings were found in the "Properties" dialog for each clip. Now, the "Properties" entry in the context menu opens up a sidebar next to the panel that shows details like the start and end times, but leaves out most of those user-configurable properties of a clip now distributed among the context-menu entries. Such rearrangements can take some getting used to.

How transitions function is another noticeable change. In the past, OpenShot's UI for adding a transition between two clips was rather distinctive. The first clip and the second clip had to be on separate tracks in the timeline, and the "transition" element was a box that straddled the two tracks and had an arrow indicating the direction of the change. It was not hard to figure out, but it certainly violated the established rules of "how timelines work in a video editor" obeyed by, well, every other video-editing application.

In the new release, the user drags the two clips in question onto the same track so that they overlap. The transition element then gets planted on top of both. It is hard to say whether or not this is an improvement; nothing seems to be floating in the middle (as was the case in the old UI), but when the clips and transitions are stacked on top of each other, they can be hard to see. Since video effects (masks, blurs, brightness adjustments, and so on) are also stackable elements, one can easily end up with a half dozen translucent rectangles and text labels sitting right on top of each other on the timeline.

The other major UI component is the animated title editor, which pops up in a window of its own, and is rather straightforward to use. OpenShot 2.0 comes with 24 animated title templates, including everything from simple "words slide in from the side of the screen" effects to complicated 3D elements like a Star-Wars –style opening crawl and map flyover similar to those seen in Indiana Jones . Each template has its own battery of settings; the user adjusts them as desired (using a preview window to double-check the output), then OpenShot renders the template into a video clip to add to the timeline.

Apart from the basics, the release notes highlight several new UI features in the 2.0 series. One is a "multiple clip add" tool; for users importing a large collection of clips into a project, this tool can be used to automatically add them all to the timeline at once, with an optional gap added in between. Similarly, there is also a "Split Clip" tool with which the user can mark multiple sections within a longer clip and instantly extract each section into a clip of its own. This is handy for quickly cutting a long recording down into the just the interesting parts.

The new release also sports a larger selection of transitions (well over 300), and it even allows users to create and load transitions of their own. There is also a sizable assortment of newly added static (i.e., non-animated) title templates. Finally, the new release adds an auto-save feature and automated backup creation, which anyone who has invested serious time in a video project will probably be thankful for at some point.

For the average user, the OpenShot 2.0 builds may appear to be little more than a release on par with contemporary open-source video editors like Pitivi or Kdenlive. But it is clear that Thomas and the other developers have put in a substantial amount of work on the non-user-visible aspects of the new release, too. There are fewer application crashes now, since the front-end catches most exceptions. Libopenshot is making better use of multi-core machines via OpenMP, and offering smoother animations and audio processing. The library is also better at coping with odd or corrupted video files (where, in the past, it might crash), and the project file structure has been reworked to be completely portable across operating systems.

The OpenShot 2.0 rewrite was a massive undertaking, so the development team deserves a lot of credit for getting it done and providing users with a stable end product. The bigger question will be whether or not the reworked interface and brand-new editing library allow the project to push forward. After all, fans of video editors on Linux desktops have seen rewrites and forks announced many times in the past. Some, like Cinelerra and Lumiera, never seem to actually reach the light of day. Others, like Pitivi, are more successful, but progress on new features always seems to be slow. In many respects, that is due to the inherent complexity of video editing. Hopefully, then, the OpenShot 2.0 series and new libopenshot library will prove not only to be useful for users, but to be easier for the developers to work with as time goes by.

Comments (3 posted)

Last year, I had the privilege of participating as an intern in the Outreachy program. In gratitude, I am sharing my experiences and those of my fellow Outreachy participants (the worms' eye view), as well as a bird's eye view provided by Karen Sandler, one of Outreachy's prime motivators, who generously gave her time to answer my questions.

Background

Outreachy began, under the auspices of GNOME, as a program to promote women in technology. It arranged paid internships for women, with mentors provided, so that they might gain experience in the open-source world. Today, its primary goal is to increase participation of under-represented populations in the open-source community. Last year, it expanded to include transgendered individuals and, this year, to "Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander" peoples in the US.

Since the statistics for participation by women in the open-source world are abysmal (1-11% of all participants), and are similar for these other groups, Outreachy provides a needed service. The reason the statistics are variable is due to different studies and to the methodologies used: whether only developers are counted or if documentation and other contributors are also included, for example.

For those unfamiliar with the Outreachy application process, it is not simply a matter of filling out a form. Rather, Outreachy publishes a list of projects, a brief description of each project, the project contacts, the mentors, and a desired set of skills. It is the participant's responsibility to research those that look interesting, to ensure that they have the requisite skill set, and to communicate with the mentors to determine if the project will meet the participant's goals.

Once a mentor and a participant have been matched, the two choose a small project that the participant can work on. This small project must be completed and accepted into the open-source software project before the Outreachy application is complete. This year, the application period runs until March 22, so it is definitely not too soon to begin the process, nor is it too late for mentors to volunteer. Outreachy recently sent out a plea for more mentors.

To try to get a sense for how well the program is working, I emailed the 244 Outreachy alumni to ask how many were working in the field. I received over 70 responses: most are working as developers, about 2/3 in open-source, 1/3 in the proprietary world, with a smattering in mixed environments. A few work as technical writers, one is a project manager, a few have other internships or are still students, and one is pursuing a PhD in physics. Two wrote that their companies are actively looking for women and other minorities to hire, and encouraged other past participants to apply.

Bird's eye view

Sandler has helped nurture this program since its early days. She acknowledged that she measures success in absolute numbers (41 Outreachy alumni have given presentations at conferences; fifteen have subsequently participated in Google's Summer of Code), but most of her comments focused on less-tangible impacts. She has surveyed the entire open-source world and is seeing greater numbers of contributions made by women, she said. She also is heartened to note that more women are contributing to blogs, which is a sign that women are more willing to be visible. She said that one of the advantages of this increased participation is that, as time goes on, a "critical mass" can be achieved, where members of under-represented populations will feel more comfortable.

Any member of a minority will acknowledge that when you are the only one of a group, there is a major difficulty in being visible. Any flaws or mistakes tend to be magnified, are remembered longer, and are unfairly applied to the group as a whole. Even though members of the majority may make the same mistakes, newly visible minority members often take more than their share of such criticism.

Sandler also noted that some former participants have become mentors themselves. While the numbers are still small, these "grandmentors" demonstrate that not only are some Outreachy participants getting jobs in the open-source world, they have progressed to a point where they can lend a hand to those coming behind them. Over time, this will help "change the tenor of the community", she said.

The grandmentors point to another benefit accruing to Outreachy participants: the community of alumni that is forming as a result of past participation. I regularly receive emails notifying me of other internship opportunities, as well as additional resources. To compile impressions from past participants for this article, I sent a separate email to the group. The response was heartening; sixteen people took the time to share their goals, dreams, successes, and failures.

Participants speak

The most commonly expressed goal was to become involved with open-source software. Most of the participants were still in college or had recently graduated. However, several were undergoing major career transitions; one was transitioning from the proprietary to the open-source world. Other stated goals were for exposure to a diversity of groups and people in the field and to the international nature of open source. Several noted a desire to work on something bigger than themselves, to contribute, or to gain experience, and several mentioned that the money was appreciated. One woman was working on an OpenStack project and realized that she could get paid for what she was already doing.

All the women expressed high levels of satisfaction with their experiences, although many asked to remain anonymous, so I am extending that courtesy to all of them. The most commonly mentioned successes were the amount learned, the challenges, the opportunities for collaboration, networking opportunities, the increase in confidence and of "hireability," and the impact of their work ("affecting millions," one woman wrote). All were enthusiastic about their mentors who were described as kind, patient, helpful, and supportive.

One particularly eloquent participant described how she had gone through a career transition, had taken a few on-line classes offered by major universities ("Massive Open Online Courses" or MOOCs) on JavaScript, and used her internship to gain experience in what she'd learned. She was delighted that, unlike most internships, "I didn't have to be actively enrolled and pursuing a degree to be eligible." She now credits this program with her current employment as a JavaScript developer. "I advocate at my company to put effort into recruiting in a way that encourages women to apply; to establish work policies that attract women; etc.," she wrote. This attitude is what will achieve the critical mass that Sandler spoke of.

Two women expressed some disappointment that there was not enough coding; a third, who was not coding, was delighted that she was doing usability testing. This speaks to the importance of matching one's needs and goals to the projects available, which should happen during the application process.

Some of the projects that participants worked on included writing GNOME application user help documentation, writing small test-programs for FFmpeg's API, testing new applications, and porting a program from C to C++. One participant was doing usability testing for GNOME; she was excited, because usability was the aspect of computer science that she was studying. Others wrote drivers, made sophisticated (though fairly small) kernel modifications, wrote semantic patches for Coccinelle, performed statistical analysis, worked on aspects of Air Mozilla (the multimedia arm of Mozilla), and so on.

Some participants shared links to their projects. For example, Frances Hocutt wrote the description of the "gold standard" for MediaWiki API client libraries. Lisa Fresh provided two links, one to the presentation she made at the end of her internship with Mozilla and another to the code she worked on.

My Outreachy experience

In my case, I only learned about Outreachy two days before the application deadline was closed. I had a vague notion of becoming involved in Linux kernel development. I wrote this to Marina Zhurakhinskaya, and my project found me—in the person of Lars Kurth of the Xen project. My mentors were Wei Liu and Julien Grall, who were unfailingly kind and patient with me. The application project was to provide functions to compute logical operations on two bitmaps.

My Outreachy project was to take the 9P protocol and to create Xen front- and back-ends to implement it by building on the work that had already been done with 9P in virtio. This was a difficult project, made more so by my own unique circumstances. Despite thirty years of experience, only three of them were in the Unix world and those were back in the early 1980s. I had not worked in a number of years, and during my hiatus, had suffered a minor head injury that affected my ability to read and learn. My personal goals were to determine at what level I was functioning as a contributor, where I was going to have problems in any job, and how to compensate for any deficits I might encounter.

A month into the project, my mentors asked me if the project was too hard. At that point the answer was, "no." Two weeks earlier, I would have had to say, "yes." My mentors supported me as I struggled to set up my environment, learn the tools, and come up to speed on Xen. For learning the virtio implementation, I was pretty much on my own. Learning all of that took longer than I would have liked. However, when it came to modifying virtio code, and writing Xen-specific code, I found myself discovering a joy in, and a facility for, software development that I'd forgotten I had.

My project was described variously as a proof of concept and as a prototype by my mentors. As the first, it was a definite success, because I demonstrated how this could be done and that it could work. This involved showing how few virtio files needed to be modified (they were very modular) and getting a subset of the project working. Since I never got the full finished project working, though, it was something of a failure as a prototype.

The support experienced in Outreachy made participants feel valued. Thus it was a sad postscript to my internship when someone offered to hire me to build on my work. However, since he lacked the funds to pay me, he felt I should get my work up to production quality for a proprietary product, for free, as I was "supposed" to last summer. Then he "might" hire me for add-on work. I politely refused, but I wonder how many young women would have accepted those terms. It undercut the hard work that Outreachy and its representatives put into making participants feel valued and worthwhile. This reflects a larger problem in the open-source world, where at least one developer expressed concern that he was being used, and his work misused.

That experience notwithstanding, Outreachy has been greatly appreciated by its participants, me included. I encourage all eligible people to look into it, and hope more mentors volunteer. In addition to the satisfaction of helping increase diversity, the experience of mentoring will stretch you professionally and personally. Thanks are due to all involved.

Comments (32 posted)