Hi! Today I'd like to share some thoughts about code quality and deterioration on #FOSS, also related to technical debt, maintainability and product growing. Here it is my experience with #raylib after 7 years working on it... 1/n
When I started raylib, my programming knowledge was not the same than now, I learned many things during this journey and I know there are some pieces of code that should be rewritten from scratch. That requires redesign, implementation and testing... it requires time... 2/n
If that problem happens with a small project like raylib (~50K locs) and requires a fair amount of work to review and redesign, I can't imagine how painful it could be for bigger #FOSS projects with way more years in development. Same happens with closed source project... 3/n
For example, in #raylib, rlgl layer (that connects with multiple OpenGL backends) has been redesigned at least 3 times; the window and inputs system, to accommodate every new platform; the 3d parts, to support animations; the audio module to switch to #miniaudio backend... 4/n
In my case, it required hours and hours of code review... so, I wonder how it is done with bigger projects. Code quality is high since the beginning? is it always ready to be adapted to changes? product vision is clearly defined since start? all contributors are aligned? 5/n
In my case, I chose C because it's an quite simple language, easy to read and understand, it can survive quite well the pass of time but... what about other projects using more complex or less popular languages? Project maintainability cost grows with the language complexity! 6/n
Summarizing, #FOSS projects get old and they could accumulate youth errors... but also experience. Trying to keep a project young/up-to-date implies hard decisions and A LOT of work. Sometimes, it could even seem that re-starting the project from scratch is better option... 7/7
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Today I'll share some amazing #FOSS#gamedev projects/libraries, mostly C/C++, that I like and I follow the development. First one is GLFW, a window/context/input management lib, for OpenGL and Vulkan initialization: github.com/glfw/glfw 1/n
Next one: the popular STB libraries: C/C++, single-file, header-only, self-contained, portable... The most notable ones are probably stb_image and stb_truetype, intended to load multiple image file formats and TTF/OTF fonts rasterization: github.com/nothings/stb 2/n
Next: miniaudio, a complete audio library to manage device initialization, playback and recording, supporting multiple OS and and backends... and all contained in a single portable header-only C file... just amazing! Check it out: github.com/mackron/miniau… 3/n
Usually, when checking a #FOSS project on GitHub, project Stars it's the first that draws attention, it could be a nice popularity ref. but, personally, the first info I look for is the project CONTRIBUTORS. I think it's a good sustainability indicator. Let's talk about it! 1/n
At the very end, to keep a #FOSS project alive you need people working on that project. It could be the creator, maintainers or contributors. Anyone putting some time and effort into improving the project is welcome... really? Here my experience with #raylib... 2/n
Contribution to a project usually imply following some rules, that's one reason why a CONTRIBUTING.md file is recommended to be included in the repo: github.com/raysan5/raylib…. That file could also be accompanied by a ROADMAP.md to define the project aim. 3/n
Let's talk about FOSS sustainability. DISCLAIMER: Following personal opinion is based on my experience with #raylib and following multiple gamedev opensoft libraries and tools. My perception: most FOSS out there is hardly sustainable. But let me elaborate a bit on that... 1/n
I believe most #opensource projects originate from an individual passion to create something and share it with the world. That perspective is very different from a comercial product, that is usually conceived to generate some kind of short-term long-term revenue... 2/n
A passion-driven development leads to passion-based decisions and sometimes those decisions do not fit in a bussiness-centered market. I mean, lot of FOSS is not created with revenue in mind, so, trying to make it sustainable after some time is a hard task... 3/n
Writing some code and open source it is usually the easy part of FOSS; making that code clear, accessible, organized, structured... adds a level of complexity; sharing and presenting that code to the world in a proper way suppose an humongous effort. Some details to consider: 1/n
Code tips: KEEP IT SIMPLE. Try to avoid complex code and advance language features, code should be understandable by itself with the minimum comments, keep it organized with clear file naming, add extensive descriptions with details at beginning of code files for reference... 2/n
Some languages allow easier code than others, i.e. I found C lang can be quite easy (and enjoyable) to follow but C++ can be quite complex (specially when using advance language features), making it very difficult for potential contributors to jump into the project code... 3/n
Let me start with a brief introduction of myself to FOSS. Actually, I started developing free and #opensource software with #raylib, it was 7 years ago and at that point I didn't specially care about FOSS, I just knew it was an option for soft development... 1/n
I had created several games and software in the past but it was mostly private, I actually didn't know how to make it "open source", most platforms to publish code looked quite confusing and unfriendly to me, so I hardly considered that option... 2/n
When I started #raylib development in summer 2013 I found a basic library called GLFW (github.com/glfw/glfw) to manage window and inputs, it was open source, zlib/libpng licensed. As far as I was building my software using it, I decided to use the same licensing option... 3/n
Assuming X has only three elements (A, B, and C), the Powerset of X is given by: PS(X) = {{ }, {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}}. So we have eight possibilities. In the next step, the AutoMod algoritm estimates eight equations:
Assuming X has only three elements (A, B, and C), the Powerset of X is given by: PS(X) = {{ }, {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}}. So we have eight possibilities. In the next step, the AutoMod algoritm estimates eight equations:
After that, putting in simple terms, the AutoMod chooses the most capable model in terms of predicting power. This is something very useful for applied econometricians and it guarantees you had used all the possible combinations to extract your forecasts.