Ruby
Lessons Learned While Building Hanami
Summarized using AI
Lessons Learned While Building Hanami
by Luca GuidiLuca Guidi's talk, titled "Lessons Learned While Building Hanami," presented at Ruby Day 2016, offers insights gained from nearly four years of developing Hanami, a full-stack web framework. Luca, who has a deep connection to Florence and Ruby, emphasizes the importance of humility, community, and maintaining a long-term vision in open-source development.
Key Points Discussed:
- Open Source Reality: Luca shares the contrast between public perception of open source as a collaborative space and how it often feels lonely and demanding. He urges developers to embrace contributions from others, reinforcing that no project is perfect and that improvement is a continuous journey.
- Historical Perspective: Drawing parallels from significant historical contributions, such as the Mona Lisa, he highlights the evolutionary nature of technology, focusing on the need to accept that projects may not last forever.
- Psychological Insights: Luca references the omnipotence of thought theory to discuss the realism expected in open source contributions. He encourages developers to remain open-minded and accept evolving ideas rather than clinging fiercely to their initial ones.
- Time Management: He advises developers to aim for daily incremental improvements over time to avoid burnout and maintain a healthy work-life balance.
- Monetization Challenges: Discussing open-source economics, he sheds light on the struggles of funding projects and emphasizes community support as being essential for sustainability.
- Naming Best Practices: Luca shares a lesson learned regarding choosing project names wisely to avoid legal issues, illustrating how even seemingly trivial decisions can have significant ramifications.
- Community Building: He underscores the necessity of fostering a welcoming community, advocating for clear communication, and creating safe spaces for newcomers to engage with projects without fear of judgment.
- Communication and Leadership: Emphasizing respect over authority, he encourages recognizing and appreciating all contributions to build a robust community. He concludes his talk by inviting questions and emphasizing the importance of continuous dialogue in the open-source ecosystem.
Conclusions and Takeaways:
- Stay humble and accept contributions without ego.
- Expect projects to evolve and be prepared for imperfection.
- Develop a thick skin to handle public feedback and maintain a focus on progress.
- Understand and communicate project vision clearly, ensuring accessibility for all developers.
- Prioritize community building and acknowledge the need for a supportive and inclusive environment.
- Leadership in open source is earned through respect for contributions, not positional authority.
00:00:09.519
Hello, everyone! How are you doing? I hope you're all well. I apologize for my voice—I'm a bit sick, so please bear with me. I'll be drinking a lot of water, but I'm happy to be here today. Not just because Ruby Day is an excellent conference that gets better year after year (thank you, organizers!) but also because I lived here in Florence for a year. This is where I learned Ruby by night while working a job, and I'm excited to get back to my roots and share my progress with the community so far.
00:00:58.480
Today, I want to talk about Hanami. If you don't know what Hanami is, let me Google it for you. Basically, it’s a full-stack web framework. If you haven't tried it yet, I encourage you to check it out. Tomorrow, I'll be giving a workshop in the morning, so if you're interested, please sign up. We've just released version 0.2 with many improvements in the model domain part, powered by ROM. I've been working on Hanami for almost four years. My name is Luca Guidi, and you can find me on Twitter. I work at Vienna Simple from Rome, and I want to share the lessons I've learned while building Hanami and my takeaways from my experience in open source.
00:01:45.579
First of all, this is a code-free presentation. Thank you! In this talk, we’ll learn about how old the universe is, some psychological theories, economic theories, and the teachings of a British Admiral, as well as other silly and useless facts. If you stay with me until the end, I promise we will watch together a video of cute kittens. But until then, let's talk about the vision of open source. Most of you here are probably familiar with it. Thank you for being involved. Unfortunately, most people outside of open source think it's just a bunch of smart people discussing design patterns and doing pair programming all day long. However, the reality is that open source work often feels lonely—like trying to make the CI pass for JRuby at 3 a.m.
00:02:20.000
In this field, you may feel like a genius one moment and then realize you are in the wrong career just a second later. How many of you here are actually involved with open source? Please raise your hands. For those who haven't tried contributing, you should—it’s a rewarding experience. If you’re not, please stop making your life miserable and do something better with it. Joking aside, it’s magical to see your vision come to fruition; it turns into something real that people can benefit from. Building software is like creating art; you have an idea for a painting, and you try to make it a reality.
00:02:59.350
Think about the Mona Lisa, one of the most popular paintings in history, which is over 500 years old as we speak today. It has had a substantial impact on art, yet much of humanity's other contributions overshadow it. In our daily lives, we don't appreciate the beauty of such paintings and their impact on the broader picture of the universe. Do you know how old the universe is? Approximately 14 billion years! If we consider this perspective, then probably your impact in open source will feel less significant than the Mona Lisa. My first lesson learned is to stay humble. Don't be too attached to your code. The less pride you have, the better you can lead your project. If someone submits a new contribution, accept it without hesitation if the code is good and the tests are passing—that’s for the good of the project and the community.
00:04:30.000
In a fast-paced technological world, things can quickly become outdated. Think of recent CPU generations that progress every few years, which is remarkable. Of course, there are exceptions to this rule, like COBOL, a programming language from 1959 that still has a role in the industry today. In psychology, there's a concept called the omnipotence of thought, which is a theory developed by Sigmund Freud. As children, our thinking is filled with grandiose ideas, and we genuinely believe we can accomplish anything. But as we grow, we replace those thoughts with more realistic understandings of our capabilities. This applies to open source as well—first, don't think your project will last forever in a fast-paced environment. Embrace the reality that in open source, technology evolves rapidly.
00:06:01.810
Second, don’t assume your project is perfect; perfection doesn’t exist. Every project aims to solve a specific set of problems while leaving out many others. It’s a design filled with compromises, and we know that compromises are never perfect. Therefore, aim to build software that changes habits. Hanami may seem a bit odd at first, but that’s intentional. I want to change how you build web applications using Hanami, not just regarding productivity but also concerning principles like separation of concerns and stability.
00:06:44.120
While working on your habits and wrapping your head around foundational principles, consider the historical example of version control systems. SVN had its limitations, making it cumbersome to branch and merge, whereas Git empowers developers with offline capabilities and easier branching. Let’s take smartphones, for example. The iPhone and others changed our daily lives in significant ways. The bottom line is: don't cling too tightly to your code. Remember, if it isn’t personal, nobody can hurt you. When you release a new version of your project, people can comment harshly, which might ruin your day. Unfortunately, in the realm of the Internet, out of every ten users, nine may remain silent. They may appreciate your software but will often choose to ignore it rather than comment. In contrast, one negative comment can overshadow all the positive feedback you receive.
00:09:09.040
My advice is not to try to change the internet; instead, develop a thick skin to deal with it. It’s not easy to separate your open-source persona from who you are as a person. I’ve had difficult times sticking to my advice over the years because one reason I’m involved in open source is to demonstrate my capability to create something useful for the community. But here’s the surprising answer: there’s no inspiration. There’s no magic source for inspiration. Your background knowledge in a particular field equips you to write excellent software. I’ve been a web developer throughout my entire career. I know the pain points I’ve faced on a day-to-day basis, and I want to solve those with effective solutions.
00:09:29.150
So, my advice here is not to start a project with the intention of just starting something; start with a mindset of maintaining it. Consider sticking around for the next ten years, which will only be feasible if you have a genuine interest in the field you choose for your project. You need to understand it deeply. Inspiration is out of the equation; your experience speaks louder than a fleeting muse. When I started Hanami, it wasn’t as consuming as it is now. Occasionally, your hobby can turn into a full-time job, wherein you might only be able to dedicate one hour a day to working on it. I initially started with just one hour daily to validate the proof of concept of Hanami.
00:10:27.320
I believe in making small daily improvements. It’s like watching an episode of Game of Thrones every day; you’re making progress while the characters remain static. The entire six seasons of Game of Thrones comprise 350 minutes, roughly 55 hours—that’s the time it took me to release the first two versions of Hanami's router and enemy controller. So the next time you think you don’t have time, reconsider. Sometimes, it's just a matter of turning off Netflix and doing something productive. Make progress every day, but remember that it’s okay not to work every single day. Something else is important—have a life outside of coding! Learn to cook, play with your dog, go to a movie, or take a walk with a book. Don’t allow burnout to defeat you after just six months.
00:12:59.440
It can be difficult to justify open-source work, particularly when you have a job. It's challenging to explain to your supervisor that you want to invest time in open source. It’s also hard to tell your significant other that you’re spending an extra hour at work. Unfortunately, open-source software is often an unpaid job we take on because we love it. However, we often find it hard to pay the bills. Many projects run entirely on open-source software, from operating systems to programming languages and frameworks—yet most people take it for granted. Economically, this phenomenon is referred to as the 'tragedy of the commons,' a theory that describes shared resources resulting in individual actors acting on their self-interests. Many people utilize free open-source software, yet few contribute back.
00:14:30.490
I've been funding Hanami out of my own savings. This is no longer sustainable; as you may know, monetizing open source is tough. Fortunately, initiatives like Ruby Together aim to crowd-fund developers' time and infrastructure costs for projects like Bundler and RubyGems. However, that is not enough; we need more funding, marketing, financial, and legal advice. Speaking of which, I want to share an experience regarding naming. Hanami was initially called Lettuce, which was unfortunate due to its similarity to a popular IBM office suite. I initially thought developers could distinguish between the web framework and the software suite. However, I was proven wrong; it’s like starting a techno music project called Queen.
00:16:04.740
In January, an IBM employee raised concerns about the name on our GitHub tracker, which led to legal consultations. The shocking takeaway was that trademarks require names to be outside the software industry, and you can’t just slightly alter an existing name. Even if you were never sued by IBM, you’d still be unfairly branding your project within the shadow of their well-established name. When you want to start a project, do yourself a favor and research trademark laws before deciding on a name. A quick check on websites can help you avoid problems. The unfortunate truth is that many projects face similar naming issues; I saw over 900 projects using names like Lettuce, which can lead to confusion and potential legal trouble. The next time you’re brainstorming project names, please check trademark databases and also consider name generators to find something original, even if the suggestions aren't great.
00:18:49.740
Now let's discuss a crucial aspect: fostering a community. I call this portion of the talk 'Shrink.' Think of 'Schrodinger's Cat.' A cat can be simultaneously alive and dead inside the box, just like software can be both functional and broken until people start using it. Your community is a critical component; to attract people, you must create a safe environment. This is a responsibility for all of us. If you yell at someone while they're learning, they will freeze up and will be reluctant to express their potential. The same applies to open communities; aggressive tones can deter junior developers, making them feel unwelcome.
00:21:42.420
Adopt a code of conduct as a clear assertion that you're creating a safe and welcoming atmosphere for your community. Use your skills to thank contributors every time you receive a pull request, compliment, or even critique. Everyone should acknowledge that someone took the time to interact with your project. If I ask you for help with my day job, you’re likely to decline, but if I ask for help with Hanami, a new project, you may be more inclined to assist. Communication is essential. It’s tempting to sit behind your computer and code, but the less you interact with your community, the worse it is for them. Engaging with users will not only help them feel valued but will also ensure your project meets their needs.
00:23:45.659
Make sure your concept is easy to understand because a margin of people simply may not grasp what you are saying. This doesn't mean they lack intelligence; it’s a matter of context and communication. There are varying levels of understanding, and junior developers might not read error messages closely. A teammate recently informed me of a flaw in our documentation about running a Hanami project with PostgreSQL. The error message indicating you have to start PostgreSQL was obvious to me but less so for others. I want to rewrite the guide using SQLite, as it requires no server to start. Sometimes the simplest solutions escape us because we have reached a certain level of experience.
00:26:34.810
Encourage newcomers to feel safe. Express to them that if something is broken, it’s not always their fault. Ensure that there’s a support line or chat available where they can seek guidance easily. In this chat, users should always feel they can ask for help and get a welcoming response. First impressions matter. For example, when someone tweeted about which programming language and framework to use for their next project, the extensive list of suggestions demonstrates that developers have plenty of options in today's landscape. We are competing for attention, so your first impression should clearly communicate what your project is about. Design your project's visuals and branding to reflect its identity rather than being static and outdated.
00:30:43.300
When users come across anything new, make sure their initial interactions are easy. This means having a clear README that walks potential contributors through setting up a project locally and running tests. The more burdens you place on new contributors, the chances they will abandon the idea of contributing increase. Historical figures also teach us important lessons. A British admiral once worked with corn seeds to ensure the Royal Navy would never be short on trees for shipbuilding. Like that admiral, you need to plant seeds every day to grow a community. Expanding your community isn't just for the sake of numbers; it’s essential for incorporating diverse voices and perspectives.
00:34:27.330
Lastly, remember that leadership stems from respect, not authority. There are people contributing to Hanami in this room. Recently, I made the mistake of thinking that granting authority was enough for respect. It isn't; respect comes from competence and capability. Recognize the contributions of others and give credit where it's due. I hope you all gained something valuable from my presentation today. It's been a journey building Hanami, which has taught me countless lessons, and I look forward to your questions.
00:35:53.690
Thank you for your attention. If you have any questions, feel free to ask. One topic worth discussing is whether I would have done anything differently. Initially, I struggled with global state management in my project. This reliance on globals has made maintaining and testing the project challenging. As developers who are comfortable with having globals everywhere, transitioning to a cleaner architecture can be messy. There are those here who may find value in my discovery: avoid using global states. Additionally, addressing trolling is a struggle for me personally. There are moments of temptation to engage with negative comments. When it becomes counterproductive and your peace of mind suffers, sometimes it’s best to move on.
00:41:46.330
Can you all hear me? I appreciate the discussion we've had today! Let's keep the lines of communication open as we work on building something meaningful together.
Explore all talks recorded at rubyday 2016
+1