Ramon
Dec 9, 2020
Please welcome Ramon Santamaria, @raysan5 #raylib creator
Dec 09 to 16 on @imakefoss
Interview: https://t.co/214LusrV05 Talk: https://t.co/ZFQQocT1kO
@imakefoss is a Twitter rotation curation account, an interview blog and a YouTube channel: https://t.co/AnlwtLe4rB https://t.co/nbL6a8aqHx
Dec 9, 2020
Hi! I’m Ray and I’m the creator of #raylib, a simple and easy to use library to enjoy videogames/tools/graphics programming: https://t.co/z0vSFeDwAJ I’ll be some days tweeting about my experience developing free and #opensource software for the last 7 years. Hope you enjoy it!
Dec 9, 2020
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
Dec 9, 2020
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
Dec 9, 2020
When I started #raylib development in summer 2013 I found a basic library called GLFW (https://t.co/jsDyiARzvM) 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
Dec 9, 2020
From that moment, GLFW became a reference to follow… and the first step was publishing my code on @github, a really friendly platform to publish, manage and share code projects. At that point started an amazing adventure that has lasted for 7 years now… 4/n
Dec 9, 2020
@github In that time I learned a lot about FOSS, actually, I looked at many open source libraries (mostly in C/C++) as a reference to build raylib, checking project organization, files/directories conventions, library presentation… I’ll share some of them in the following days… 5/n
Dec 9, 2020
@github I’m used to put a great care to detail in everything I do and raylib was no exception. Not only on the code itself (naming, formating, comments…) but also on all the elemements that surround code sharing. I’ve seen many ‘open source" projects that fail in that point… 6/n
Dec 9, 2020
@github Actually, most of the time I’ve put into #raylib in all those years has not probably been coding but organizing and presenting all the project in the best possible way to make it attractive to the users… and one key factor is simplicity. More on that in the next days! #kiss 7/7
Dec 10, 2020
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
Dec 10, 2020
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
Dec 10, 2020
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
Dec 10, 2020
GitHub tips: Always place a detailed README and LICENSE in the repo, CHANGELOG, CONTRIBUTING and ROADMAP are also recommended. Select carefully a project description sentence and try to add some distinctive logo/image to identify the project… It worked good for #raylib. 4/n
Dec 10, 2020
README tips: Start with a clear project description and aim of the project, project features, usage details, project building and installation, documentation references, contact information and social networks, license reference. Some info could be moved to other files… 5/n
Dec 10, 2020
CONTRIBUTING tips: A file with some contribution guidelines is very useful! You can list project naming conventions (dir/files/code) as well as project phylosophy and aims. Also, provide issues/PR/examples/demos templates for contributors to make it easier to start. 6/n
Dec 10, 2020
Building a community around your FOSS project is key to find contributors and make the project grow, also, it’s a great motivator to keep working on the project. With #raylib I tried several options: forum, reddit, gitter, irc… best one? Discord: https://t.co/u1txWti3Fw 7/n
Dec 10, 2020
Managing a FOSS community requires an extra level of commitment and dedication to answer user questions, provide some support ir just talk about the project… in the last year #raylib Discord has taken a great amount of my time but library popularity has grown exponentially! 8/n
Dec 10, 2020
Summarizing, keeping a FOSS project alive and growing requires lot of work and time, not only writing code or solving bugs but also managing other aspects as project sharing and presentation. Now the question: is it sustainable? for how long? Wait for my next thread! 9/9 @raysan5
Dec 10, 2020
Dec 11th, 5:00 pm UTC An interview with @raysan5
Live: https://t.co/ZFQQocT1kO
Ramon, will report on the creation of #raylib. He will show us real-time demos and live coding and @peripateticacad will also talk to him about one of his other passions, the production of olive oil! https://t.co/6wQYC2aRD4
Dec 11, 2020
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
Dec 11, 2020
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
Dec 11, 2020
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
Dec 11, 2020
My experience with #raylib: To date I’ve put thousands of hours into the library, I can measure it quite accurately because I had a rented office to work on it and I even had a timetable to work there around 4-6 hours daily… (after my 6 hours job as a gamedev teacher) 4/n
Dec 11, 2020
After the first 5 years working on it, I had put so much time and money into #raylib that it couldn’t be sustainable by most startups… but actually for me it was great, it was like doing a new career, learning things that I loved and creating something amazing! #passion 5/n
Dec 11, 2020
But I realize that this is not sustaible. How long can you stay motivated? How much passion do you need to keep working on the same project for 7 years, almost daily? In those years I’ve seen MANY similar #opensource projects in github that just stop updating after 3-4 years. 6/n
Dec 11, 2020
I checked a LOT of FOSS projects in the last years trying to find some formula to make #raylib sustainable, at least to get a minimum income to allow me to work on it fulltime. I haven’t found it yet but I noticed several things that most sustainable FOSS have in common: 7/n
Dec 11, 2020
- Great care for the product: Very nice web, detailed repo with lot of information, nice documentation.
- A big community created around it. Usually through several social networks.
- The FOSS allows user to generate revenue using it! And that’s a very interesting point! 8/n
Dec 11, 2020
So, my perception is that FOSS that can be used to generate revenue in some way is more prone to become sustainable (through donations, contributors, supporters…) than projects that focus on other types of added value (i.e. experimentation, learning, testing…)… 9/n
Dec 11, 2020
@henne I mean being able to keep the project alive. It requires lot of time (and sometimes money), specially if the project keeps growing and a community is created around it.
Dec 11, 2020
#raylib is mostly used, afaik, by students and hobbyist, to enjoy games/graphics programing, it does not provide a simple way for users to generate revenue (I already tried it on @raylibtech) So, if I stop maintaining/supporting it, could it survive? Feel free to answer! ;) 10/10
Dec 12, 2020
In case you missed the interview with Ray and Monica about #raylib, #FOSS game development and olive oil, you can watch it here. And we are happy about your subscription to the @imakefoss #YouTube channel. Thank you!
https://t.co/ZFQQocT1kO https://t.co/iDrD3PXdQK
Dec 12, 2020
Let’s talk a bit about MOTIVATION on #FOSS. How much do you need? How can it be maintained?How long can it last? Here it my experience working with #raylib for +7 years… SPOILER: It’s not possible to be motivated all the time! 1/n
Dec 12, 2020
Original motivation: #raylib started as a weekend project, for my students to learn programming and be able to easily put things on the screen… also view/understand what was happening at a lower level (#opensource)! The idea itself seemed cool enough to motivate me a lot! 2/n
Dec 12, 2020
Results motivation: Students loved raylib and they started learning and creating things in just a few weeks… that was a great motivation to keep working, improving the library and adding new features! I received lot of positive feedback and engagement! Very motivating! 3/n
Dec 12, 2020
Learning motivation: As #raylib kept growing with new features, I started learning about new fields that seemed very interesting to me (#Android, #RPI, #VR, compression, graphics…). Learning new things everyday and make them work with #raylib was very motivating! 4/n
Dec 12, 2020
Feedback motivation: As a result of that learning process, I started other related #FOSS projects using raylib that actually, kept my engaged with raylib! Some examples are #raygui (immediate-mode gui lib), #rres (custom file-format), #rfxgen, #rpng… and lastly @raylibtech. 5/n
Dec 12, 2020
@raylibtech Community motivation: Probably one of the most powerful sources of motivation (but also demotivation) that a #FOSS project can get. It’s AMAZING to see people from around the world creating things with #raylib and taking about it! But, sometimes, there is also a dark side… 6/n
Dec 12, 2020
@raylibtech From time to time you find people that demotivates you: harsh/mocking comments, disrespectful complaints, features demanding with impatience and insistence… to name just a few. Those situations can be really demotivating for a #FOSS developer… 7/n
Dec 12, 2020
@raylibtech Fortunately, in the last 7 years working on raylib with a community of thousands of people I only faced those demotivation situations a few times… Most raylib users always keep in mind that raylib is a #FOSS project and they are very educated and respectful! I love it! :D 8/n
Dec 12, 2020
@raylibtech Recognition motivation: Finally, I must admit that being awarded with Google Open Source Peer Bonus / #EpicMegaGrants or having the opportunity to share my thoughts on @handmade_seattl / @imakefoss is also a great motivation to keep working on #raylib. Thank you very much! 9/9
Dec 13, 2020
After my last two threads about #raylib #FOSS SUSTAINABILITY and MOTIVATION, today I’m going to talk about a tightly related topic: MONEY. Is it required for the survival of a project? How much is required? What options are available to get some? Here it is my experience… 1/n
Dec 13, 2020
I think a #FOSS project can survive with no money but once it becomes more demanding (improvements, features, community…), it requires more time and money could help to get that extra time to be put on the project grow. We can even see some #FOSS project turning into orgs.! 2/n
Dec 13, 2020
In the case of #raylib, I tried to keep the project small and under control… but that’s not easy and in the last two years community has grown exponentially! My option to finance it: working as a full-time #gamedev teacher/lecturer, a job that really takes lot of my time! 3/n
Dec 13, 2020
I tried part-time and even quitting job to get time to keep working on #raylib/@raylibtech but, in my case, it was not economically sustainable for too long (up to 1.5 years limit). So, I tried with several donation networks to get some extra money, that’s what I got to date: 4/n
Dec 13, 2020
@raylibtech I setup Patreon, Ko-fi, https://t.co/9dM3DEYLS6, PayPal and GitHub Sponsors to allow donations… and right now, after 7 years, I’m getting around $250 month from all of them combined… that’s more than what I ever expected but it’s not enough to live from it… 5/n
Dec 13, 2020
@raylibtech Last August I received the biggest contribution to date, an Epic MegaGrant, that was $15K (about 8-9K€ after taxes), still planning what to do with that money but it will allow me to move part-time job again, to have more time to work on #raylib (at least for some months) 6/n
Dec 13, 2020
@raylibtech So, here the questions again: is it sustainable? for how long? how long could motivation last? forever? could #raylib be used to generate revenue and, consequently, generate enough donators to get enough money to work on it full-time? Let’s bet on raylib for a bit longer! ;) 7/7
Dec 14, 2020
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
Dec 14, 2020
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
Dec 14, 2020
Contribution to a project usually imply following some rules, that’s one reason why a https://t.co/wqk9hzI6M3 file is recommended to be included in the repo: https://t.co/pRGR2MmoSU. That file could also be accompanied by a https://t.co/ReKxR6nZQw to define the project aim. 3/n
Dec 14, 2020
Those files try to define the original objective and intention for the project, the background, some technical aspects like code organization or naming conventions and even recommended procedures to follow when contributing to it. My experience: some people do not read it. 4/n
Dec 14, 2020
In many cases, it’s just small bug fixes or improvements that I can happily review in some minutes… but from time to time I receive big chunks of code with new features or library redesigns… Here comes the dilemma: accept the PR or refuse it. Not an easy decision! 5/n
Dec 14, 2020
My rule of thumb is maintainability. Should I be able to maintain it? What would be the technical/time cost to do that? How much makes it grow the library? In what direction? PR creator is going to maintain it? How long? Sometimes I refused great PRs just for those reasons… 6/n
Dec 14, 2020
So, for #raylib the best contributions are always small fixes and improvements, maybe a self-contained code example, build system tweaks or even testing reports and showcases. From time to time I merged big changes (UWP, RPI4 backends) but it requires a maintenance effort! 7/7
Dec 15, 2020
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
Dec 15, 2020
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
Dec 15, 2020
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
Dec 15, 2020
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
Dec 15, 2020
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
Dec 15, 2020
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
Dec 15, 2020
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