00:00:09.160
Okay, this is the last presentation of the day.
00:00:28.960
Hi everyone.
00:00:39.960
I know, I know, okay good luck.
00:00:49.199
I tend to drift away during presentations, so please feel free to ask questions whenever you want.
00:00:57.359
I work in security at my daily job and do open source work. Looking at open source gives me an interesting perspective.
00:01:04.239
I mainly focus on Ruby, JavaScript, and npm.
00:01:12.960
When I started creating this presentation, I wanted to convince you that doing open source is fun and doable, and that you can make friends through it.
00:01:31.240
You can merge building new, cool stuff with making it maintainable.
00:01:37.479
However, two days ago, someone complained about encountering repeated errors while trying to refresh their page.
00:01:49.320
This got me thinking about the fact that you're not obligated to anyone when it comes to open source work.
00:02:02.439
If you need to take anything away from this talk, keep in mind that if you are doing open source, you owe nothing to anyone. It's not exactly free labor, but you have the freedom to choose.
00:02:31.400
Today, I'll discuss my experiences with creating gems and the many mistakes I've made.
00:02:41.480
This talk contains around 160 slides where I explain how I messed things up and how others have opened numerous issues.
00:02:53.120
This led me to ponder better approaches to open source development.
00:03:03.920
Let me start by explaining how I began creating gems.
00:03:10.400
I simply had my own needs and silly ideas.
00:03:16.360
As a result, I often came up with ridiculous solutions.
00:03:24.799
I never intended to create anything popular; I made gems and wrote comments in Polish.
00:03:32.000
This did wonders for developer experience, especially since, back in those days, a lot of Ruby comments were in Japanese.
00:03:42.599
I asked a guy in Japan why some Ruby documentation wasn't in English, and he chuckled that it wasn't even available in Japanese.
00:03:49.000
Among all the gems I've built, this one is my favorite.
00:03:54.439
It has 100,000 downloads and is literally empty.
00:04:01.599
I have a tendency to attend conferences and when people announce projects like Solid Q or Mission Control, I often take those names for myself.
00:04:06.883
When I look at gems and applications, I see they are getting increasingly complex.
00:04:18.120
I acquired about 260 gems, like Mission Control, and I gave a couple back to their original owners.
00:04:28.240
I even built one called ICQ, which is a Polish messaging service from 15-20 years ago.
00:04:37.760
I created a gem for it before agent technology was popular because I wanted users of my outdated website to send me messages.
00:04:48.000
I based it on someone's thesis about hacking the API in C, and then I implemented it in Ruby.
00:04:54.400
Surprisingly, people started complaining about my open-source project stating that their messages weren't delivered.
00:05:01.680
This is something I now deal with regularly.
00:05:09.600
I also built an FNFA framework out of sheer laziness when working with people who didn't want to learn hype-driven development in 2014.
00:05:16.040
My good friend introduced me to a technology that promised to solve all our problems, but it did not help me.
00:05:23.600
When you build gems, they start simple but quickly become complex.
00:05:30.080
This phenomenon occurred in my experience as well.
00:05:39.080
I avoided explaining processes and complicated elements to others.
00:05:46.880
This led to me abstracting whatever I could.
00:05:53.680
Sometimes this approach can result in difficulties in understanding and using your gems.
00:06:01.440
When you look at the open source Ruby space, you see many influences from Rails.
00:06:09.760
Some developers are very cautious about dependency management, while others are carefree in their approach.
00:06:16.480
Over the years, I've come to understand some factors that can simplify the creation of gems.
00:06:25.440
Rails is a solid framework that many developers appreciate, and I've built decent software with it.
00:06:32.440
One challenge with Rails is that while it simplifies gem development, it introduces its own complexities.
00:06:41.440
If you introduce Rails as a dependency, it also becomes a transitive dependency for others.
00:06:48.880
When providing a gem with generic functionalities, it can become complex to test.
00:06:55.160
It's crucial to make your libraries work with Rails while also allowing them to operate outside of the Rails environment.
00:07:05.760
This ensures users have the flexibility to use the gem according to their needs.
00:07:16.160
Detecting that Rails is being utilized can help you seamlessly integrate your gem.
00:07:24.160
You can also work around Rails to effectively coordinate your gem.
00:07:31.919
Dependency management remains a critical topic in gem development.
00:07:40.080
Every dependency you add is a liability, and this applies to applications as well.
00:07:47.760
If you add a dependency, keep an eye on potential breaking changes and security concerns.
00:07:56.560
In gem development, you function as a liaison, meaning user constraints significantly affect the final result.
00:08:03.920
A few years back, my approach was to rely heavily on gems to handle everything for me.
00:08:15.159
Eventually, I faced a barrage of issues from users and began to reconsider my strategy.
00:08:23.720
I thought about reducing my dependencies where possible.
00:08:29.919
I had 58 dependencies in my ecosystem and reduced it to 9 or 10, which felt liberating.
00:08:36.840
Fewer dependencies meant fewer problems, but it also introduced its own set of challenges.
00:08:43.680
While it had benefits, the core issue remained—my software was crashing.
00:08:51.120
When events like this happen, you can either fix them on your end or try to work around the library and pretend it never occurred.
00:09:04.480
This can weigh heavily on the decision of whether to keep using that library.
00:09:11.840
If a library experiences critical vulnerabilities, the community generally demands swift action.
00:09:18.560
You can indeed start removing dependencies from your project.
00:09:26.480
I had previously built about 2,000 lines of code around certain dependencies.
00:09:33.360
Reducing this number allows for more maintainability.
00:09:43.760
Eventually, I faced challenges with the dry ecosystem that led to malfunctioning aspects of my software.
00:09:51.200
Realizing that dependencies can lead to issues with applications illustrated the connection to the supply chain.
00:09:58.160
Let’s discuss the intriguing aspects of licensing in open source.
00:10:07.160
When dealing with your libraries, ensure to think through the licensing implications.
00:10:16.160
Choosing the wrong license can severely impact your long-term maintenance strategies.
00:10:24.560
Remember to set up a contributor license agreement to avoid legal challenges down the line.
00:10:32.160
This is essential, especially when incorporating external contributions.
00:10:41.120
Consider these points as you navigate the open-source landscape.
00:10:48.960
Finally, let's address an important takeaway: the significance of good documentation.
00:10:56.520
Having clear, concise, and accessible documentation makes your libraries more user-friendly.
00:11:06.240
Utilizing public APIs can enhance your library's usability, ensuring it caters to various use cases.
00:11:15.840
It's important to provide users with guidance about integrating and implementing your library.
00:11:26.560
When developing software in open source, your community's feedback is invaluable.
00:11:35.360
Embracing diverse use cases will help you enhance your software's functionality.
00:11:44.720
Receiving diverse feedback greatly enriches your programming approach.
00:11:53.440
Thank you for listening, and I hope my experiences help you in your open-source endeavors.
00:12:03.440
If you have any questions or feedback, I'll be at the afterparty.
00:12:12.160
Thank you for your time!