Thanks for the thoughts and questions, Noah. It's definitely not all done in my free time. My company uses it extensively, so I do write code "on the clock", certainly for the sections directly relevant to us (like oiiotool, the texture system, file formats we use, and any parts of the codebase used by OSL; though for areas wholly irrelevant to VFX work, I avoid during the workday). Others in my company also sometimes work on patches, when they need specific things.
OIIO also gets contributions from many people at other VFX companies, though I have no way of knowing if they are working on company time. In some projects, like OpenColorIO, it is very clear that a substantial portion of the work is done as people's day job. That's definitely not the case for OIIO -- even for me, it's not my only coding project, and writing code myself isn't the majority of my professional responsibilities. Nobody's full time job is to improve OIIO, despite it being used ubiquitously by all the largest VFX and animation companies. (As an aside, I think an important part of moving forward as an industry is normalizing the idea of engineers improving the critical open source projects their companies use, just as freely and prolifically as they would for an important in-house package.) The big danger, I think, is simply that this all looks like it's working totally smoothly from the outside, and thus the companies depending on it think no help is needed or that they can't offer much. But from the inside, it feels like I'm adding "to do" items faster than I'm completing them, issues and mail I should be answering fall through the cracks or go a long time without a response, and there are lots of great ideas I start and never quite get around to finishing. There is So Much To Do to keep this moving forward. It's not only that we'd all be in trouble if anything happened to me, it's also that it could be better, faster, more feature-rich right now if more people shared the load. A project like this is like a swan that looks totally calm above the water, but below the surface, its legs are always paddling furiously and you wouldn't believe the energy it takes to keep that up. My earlier email just jotted down a few high priority items off the top of my head, but it was not meant to be comprehensive. Yes, a better web site would be great! So would a real logo. And a good "getting started / installation" guide, especially for Windows. I think our online technical docs are amazing and comprehensive, but I'm sure they could also be improved and certainly made more attractive. You mentioned OpenColorIO. That project (which not so long ago was by all accounts "troubled") is definitely something OIIO should aspire to. They have an active technical steering committee, working groups to tackle large tasks, and many regular committers from a bunch of different companies. We sure could use all of those things. OpenColorIO achieved a lot of their current level of organizational health after (and I'd like to think because of) becoming an ASWF project. Maybe that's something OIIO should do as well. I'm certainly interested in hearing whether people think that would be a benefit to the project and the downstream users. (Though to be blunt, hearing "yes, join" is not very helpful compared to hearing "yes, join, and if you do, I will be on your TSC and I'll step up how much time I can directly work on the project." Joining would just add more work to my plate, unless it is truly a path to much more participation from others.) OpenColorIO's contributors include at least 2-3 people whose full-time jobs (or at least a substantial part of their work day) is working on the code. OIIO may be at a maturity level where that degree of constant work is not needed. I'm really not asking for full time developers. But several people who could each commit 1/4 time would absolutely turbocharge the project. There are many areas (such as I listed, and many more) where each would only need a few hours a week on average, but just having one person consistently responsible for it would make the whole thing hum like a well oiled machine. If I'm not constantly task switching between 20 different aspects of this project, I could make much faster progress on the sections where I probably am the single best person for the job. > On Apr 24, 2022, at 12:24 PM, Noah Rahm <correctsyn...@yahoo.com> wrote: > > Congrats on 14 years, Larry! > > If I may ask, is the OIIO project supported by companies or is this something > you do fully in your free time? Either way, thanks for maintaining this for > so long. > > I've been thinking how it is odd that OpenImageIO is so used and well-know as > you mentioned and yet it doesn't really have a decent website, unlike similar > projects like OpenColorIO, etc. Is there a reason for that? If I remember > correctly, there was some sort of working group that did OCIOs but I don't > think OIIO was a part of it. > > Maybe the joke is: OIIO is so well-known and used ubiquitously so that there > isn't a need to have a website to promote it...;) > > Jokes aside, I noticed you didn't list that in your help wanted so maybe a > website would be "fixing something that isn't broken" and/or not a priority? > > > On Friday, April 22, 2022, 12:47:28 AM CDT, Larry Gritz <l...@larrygritz.com> > wrote: > > > 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 <mailto:l...@larrygritz.com> > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
