Sorry, my delay on this didn't mean anything other than it was a busy week.
If you're inclined to help with a nicer web site or finally making us a decent logo, definitely I'm all ears. I think just opening a new thread here on the email list, or maybe better would be on the "discussions" (https://github.com/OpenImageIO/oiio/discussions <https://github.com/OpenImageIO/oiio/discussions>) section of our GitHub, would be a great place to kick off the topic. I think the content of our technical docs are in great shape already; writing the primary docs isn't really the help I need most. I mainly was referring to how the docs could be improved aesthetically by somebody who had more of an eye toward and experience with such things. But one area where I *do* need help on the docs content: describing how to build/install OIIO, especially for non-developers and on platforms that I don't personally use, like Windows, and keeping those docs up to date. > On Apr 25, 2022, at 12:33 PM, Noah Rahm <correctsyn...@yahoo.com> wrote: > > Thanks for the detailed response, Larry. > > > 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. > > I agree with the points you've made regarding open-source. It seems that > many open-source projects have the same problem. We (many times unknowingly) > take for granted open-source software and don't realize how ubiquitous > open-source is and that it is often one or two people carrying the load. I > haven't contributed to open-source as long as you, but I have felt your pain. > > > 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. > > I am a web designer/developer so I could help with creating a logo and > possibly the website as time permits. For that, would you like to continue > discussing here on the list or by another means? > > Not sure I can help writing any technical docs though. I'll note that I've > only used OIIO from Python and have yet to successfully build the c++ version > (probably due to my lack of c++ proficiency). > > > On Monday, April 25, 2022, 12:36:32 AM CDT, Larry Gritz <l...@larrygritz.com> > wrote: > > > 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 >> <mailto: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 >> <mailto: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 <mailto:Oiio-dev@lists.openimageio.org> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > 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
