Participating in Open Source Projects

I think I’m in the same boat as you. The dwindling day-job is all about aerospace, and my hobbies do not relate at all to that. My primary concern is with intellectual property, being able to contribute to that at work on their terms, but being able to contribute to my personal endeavors on my terms.

But the day-job is what enables me to do open-source software development. it maintains the household, so to speak, and lets me dabble with software for not only photography, but model railroad control and other things that interest me personally. Others are not so fortunate, in that their core interests are firmly anchored in their profession. The backstory behind the development and sustainment of the Network Time Protocol (NTP) is illustrative in that regard.

For better or worse, the world is organized around structures where individuals need to work at something to nuture their survival and comfort. The concept of open-source software challenges this, as it requires one to make effort that doesn’t necessarily contribute to their participation in the “structure”. Not directly, at least; in my case, doing open-source software has definitely helped me at work in keeping up with things like C++ evolution. But I couldn’t tell you what part of my paycheck directly benefited from that connection…

4 Likes

It’s also amazing to me the number of core/essential tools being maintained by just a small team not getting really compensated by so many others using the tool. A good example is Werner Koch and GNU Privacy Guard (GPG):

Or most of the webcam drivers for Linux from Michel:

4 Likes

Hopefully! Some projects never get a significant base of co-developers and as a result wither and die when the lead burns out. They may get picked up again years later (this appears to be the case for siril), although it’s always in this case a rougher transition than if there’s a slow and gentle handoff.

Years ago, myself and a few other developers founded an AOSP-derivative Android firmware project (Omni) in reaction to a licensing dispute over the Focal camera app that had been written by one of the other developers for CyanogenMod. I made a point of mentoring new developers as best as I could, giving advice on workflows (keep your commits verbose and descriptive, don’t make megacommits, comment your code, this is roughly how this part of Android is architectured, I don’t have time to improve Y but you might want to look at subcomponent Y, etc.)

At this point I’m less proud of the software than of the organization that sprang from my efforts. (Not to say that I’m not proud of the software, there were a number of cases where we outperformed an organization with massive venture capital funding for certain metrics… Strangely, those metrics were in theory at least the ones most important to said company continuing to exist, which is why I’m not surprised they had massive layoffs and “pivoted” after three years.) I eventually burned out and slowly wound down my involvement to the point where I haven’t made a commit to the project in years. (Also, upstream AOSP and stock Android have improved to the point where I don’t even bother with custom firmware any more.) Because I wound down slowly and tried to educate so many others, the project is still (or at least appears to be) healthy 3-4 years onwards.

5 Likes

This is pretty much how it actually works:

open_source_development

3 Likes

I didn’t know that. I’m working on LOS right now. However Android is still a horrible community. However Omni is a bit better place in that community :wink:

Sometimes I wish I could code. However, I decided to walk a different path in life. Since I’m using software like GIMP and Darktable I figured I’d participate in the community by creating tutorials. That way I’m not only consuming but contributing as well. Because I don’t know how to code, but I do know how to create videos :)!

5 Likes

Yeah, Android in general is a pretty horrible community. It doesn’t help that the way Google runs AOSP seriously discourages upstreaming. I heard at one point that some Android engineers at Google were disappointed at how little was being upstreamed from all of the AOSP-derivative projects, but what you you expect when:

  1. You keep your active development in hidden branches, publishing publically only once per year, leading to a high risk someone’s upstreaming effort will just silently get ignored because Google is NOT going to tell you low-level details of what’s coming in a future release - so you don’t even get a “yeah this conflicts with something we’re already working on” until you see it in the next public release.
  2. You restrict your hardware support to only your own devices, which effectively means that 75%+ of people who MIGHT have something upstreamable don’t actually own a device that allows them to test against YOUR codebase. See the results of Sony’s attempts to upstream support for their NFC chipset - it was -2ed due to not being in a Nexus device. 9 months later, a Googler submitted nearly identical patches for the exact same chipset and they were accepted. (No surprise, the next Nexus/Pixel product had that chipset.) When questions were asked about what was going on (pointing to the old patchset) - no comment.

XDA is a mixed bag. There’s not really any viable replacement for it, but since it’s such a large forum with so many people, there’s a lot of malfeasance that winds up falling through the cracks, because the really knowledgeable developers don’t want to also deal with moderation, so sometimes mods screw up. However if you can prove that someone is taking someone else’s work without proper credit, they WILL react. I actually wound up getting one guy banned because I was able to prove with diff that:

  1. Their “lionheart” governor was just “conservative” with 2-3 lines changed
  2. Those 2-3 lines were written by another developer (netarchy) without credit.

Some of the projects outside of CM/LOS do have good communication - Alex Cruz of Dirty Unicorns and the Omni guys get along well. CM’s leadership were always arrogant and drove a lot of people away, and their behavior when Cyngn was founded deepened the rift even further to an unrepairable state. We also got along well with SOME of the PA guys, but not all. PA was basically destroyed by the OnePlus hiring mess. All of the developers that got hired became completely inactive in PA, but sought to kick out anyone who was critical of OnePlus’ negative impacts on PA. One of the PA developers disappeared for months, only to resume activity SOLELY to kick out the critics - even at a time when half of the OnePlus PA hires had already given notice that they were leaving the company within a month or were seriously considering it. None of them ever resumed activity in Android circles afterwards to my knowledge.

I’m not against commercial involvement in Open Source (The Linux kernel is a great example of a GOOD working relationship), but Cyngn and OnePlus are perfect examples of how NOT to model a healthy relationship between a commercial company and an opensource community project.

Gotta go…

Edit: The community here overall is much better. There are a few severely abrasive personalities, but overall there is a much greater amount of cooperation.

1 Like

I was just wondering, is there any kind of “future vision” for filmulator,
long-term goals, project vision, etc. You name it.

I’m still low-key looking for the new ship to sail with in the raw development department,
and technology-wise filmulator seems to check many of the boxes.

The UI is already decent for experienced users given how simple I’ve kept it, but it’s not clear for beginner users how to start off, so I need to improve the onboarding process somehow.

Technical aspects of image processing? I’m planning on adding Lensfun for distortion correction. Maybe when hanatos’s Vulkan experiment is further along I’ll redo the Filmulator pipeline for insanely fast GPU computation.

For organization, I want to add tagging support to the library.

Finally, I want to have various output options: batch resizing, output sharpening, maybe contact sheet generation.