Looks like today is 14 years since the first commit -- Happy oiioversary! First commit was Apr 21, 2008, first "public" release Sep 1, 2008, first commit by somebody other than me Oct 22, 2008 (David Gordon). Since then, it has had 175 contributors (approximately... I've done my best to not forget anybody, nor to double count people who used multiple emails or identities), just shy of 4000 PRs/Issues, and has 1429 stars on GitHub.
So huge thanks to all the users and contributors to OIIO over the years. It's not an exaggeration to say that it's used extensively in nearly every large VFX or animation studio, has been used on hundreds of films, as well as embedded in a whole bunch of interesting products. As we careen toward age 15, I think it's a good time to take stock of the state of the project and what we should be focusing on over the next year. Here are a few things I've been thinking about lately. Release cycle and support strategy ---------------------------------- To better synchronize with other projects in our ecosystem and the VFX Platform (even though OIIO is not part of VP), we're going to have our major releases in mid-to-late summer (as we did last year). We used to often have big releases in Q4, but now I think that's too late for users and applications who need to have their versioning strategy settled for the next year's products somewhat earlier. (Thus, we are aiming for early August for OIIO 2.4.) Throughout the year, we will continue to have a first-of-each-month patch release of the "current" release family (2.3, now). These never break API, ABI, or link back-compatibility within that release family. The VFX Platform group now recommends support going back three years prior to the current. For us, that means we ensure that OIIO 2.3 definitely builds with the compilers and dependencies listed back through VP2019 (and any other dependencies as they existed in 2019, even if not on the VP list). In practice, we don't support our own prior 3 releases. We give continuous support and monthly patches for the "current" release family. We will also occasionally patch the previous release family (now 2.2), but less regularly, generally only for the most critical bug fixes, and only if there's an indication that many people are still using that old release and are unable to upgrade. In practice, we never patch the "year - 2" release, let alone year-3. Development cadence experiment ------------------------------ We've been pretty good at hitting patch releases at the beginning of every month, but I have noticed that I tend to get very distracted with little housekeeping tasks that pop up all the time. This year I'm going to try a new experiment to refine the process further and impose a little more structure and rhythm. For the first week of the month, right after the release, I will aim to pay down technical debt -- backporting/merging things that were delayed as the release approached, addressing backlogged bugs or email I've ignored, and making any desired improvements to the build system and CI. During the middle two weeks especially, I will try to go full-bore on feature development and other substantive improvements, trying to maximize concentration time and assiduously avoid the temptation to endlessly tinker with build and CI issues. In the last week of each month, the week prior to release, I'm going to do a semi-freeze and avoid backporting anything that isn't a fairly important bug fix, or working on docs, to make release day more of a nothingburger. Help Wanted ----------- I would like the next year to be a time in which we transition OpenImageIO to having a smaller portion of important tasks bottlenecked on my time specifically. I think this is one of those projects that appears to run so smoothy that it's easy for people to forget just how much work goes into it, and they think no help is needed. Nothing could be further from the truth! I need your help to keep this ship moving forward. There are a few particular areas that would be especially wonderful for people to step forward and take real ownership. That doesn't mean that smaller or more sporadic help in other areas wouldn't be great; I'm just pointing out a few particularly meaty topics where people could make a big contribution, areas that could really stand to have a named responsible party. * Windows lead - This is probably the biggest single role that would let me sleep better at night and improve the project for the most users. - Create simple, clear documentation for how to build OIIO and its dependencies on Windows. - Be our resident Windows expert, consult as needed. - Keep tabs on the Windows CI, improve as needed. - Triage and address Windows-specific issues. - Watch for PRs and chime in with review comments on things that might negatively affect Windows users. - Work towards a strategy for providing pre-built Windows binaries so that only people intending to help develop OIIO truly need to build OIIO and its dependencies from source in most circumstances. * Python lead - Be a frequent user of OIIO from Python. - Keep up with new releases of Python and Pybind11, make changes on our side to keep pace. - Triage, respond to, and fix issues and PRs that are related to Python. - Be the code owner / responsible developer for our Python bindings. - Keep an eye on whether our Python bindings are sufficiently Pythonic and helpful to fluent Python user. - Suggest and implement changes as needed to improve the experience of Python users. - Do the magic to allow Pip users to easily install OIIO. * Code owner of any particular image file format readers/writers. (Multiple such roles can exist.) - You regularly use and depend on file format X. - You are fluent (or would like to be) with the dependent API/library that implements the X format. - Be the responsible party in charge of the code in OIIO implementing format X. - Participate in the dependency's community and represent our interests. - Make sure our testsuite adequately tests all important features of format X. - As needed, improve completeness or performance of our implementation. - Jump in on issues or PRs related to format X. * Packaging managers (one or several) - OIIO releases show up in various packaging systems (Homebrew, vcpkg, etc.). Traditionally, we have nothing to do with this. - Take command of one or more of these packaging tasks. - Represent our project to those teams. - When we have a release, be sure the downstream packager keeps up. - Make sure that any "local" patches the downstream packager applies to OIIO are properly upstreamed back to us. * Rust lead - The ASWF Rust Working Group is wrapping up OpenEXR/Imath Rust bindings, and is targeting OIIO next. - Help them get this done. - Help maintain and improve the OIIO Rust bindings moving forward, particularly for any related code that lives in our repo. - Make sure that as new features and classes are added to the C++ APIs, the Rust APIs keep pace. - Evangelize, document, etc. Represent our interests to the Rust world and vice versa. Reduce the "bus factor" ----------------------- Maybe this is largely a restatement of the "help wanted" section, but let's put it as bluntly as possible: It's actually not healthy how much of this project is bottlenecked on me, and for how many areas I'm the only person with deep knowledge of how things work. Don't worry, I'm not planning on going anywhere! But I would sleep better knowing that if something happened to me, there are others ready and able to step in and keep things running smoothly in every conceivable area. There is no project or organization in which it's a good thing for the absence of any one person to significantly disable the operation. A year from now, I'd like to look back and see that we've taken significant steps toward shared stakeholder responsibility for the project and resilience with respect to any one person being unavailable for an extended time. -- Larry Gritz l...@larrygritz.com _______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
