Do you have any connection to whom you can easily reach out to talk about open-source and the journey of creating an open-source project? Well, now you do!

In the last work break (commonly called unemployment), I decided to take on a challenge and upskill a bit of open source.

I started with an idea. As you might anticipate, it was an untested concept. Did it end up positive or negative? You will have to stay till the end to figure it out.

It is worth mentioning right from the start that the functions package is in the developer testing phase. That is a fancy phrase that should be understood as — I will be using it and finding all the nasty bugs, so you don't have to.

What functions is not

The functions tool is not an instrument to solve all the FaaS issues you might have in your project.

It won't magically teach you how to build serverless components, but it will help you get started.

It won't make your code deployable within any infrastructure (even though this is the goal), but it will be enough to deploy basic GCP cloud functions and run your local code in a docker container locally.

Most importantly, it is not a production-ready, stable and long-term project. It is a side project built with a solid foundation for documenting as you go. Development might continue, or this might as far as things go.

We will see how things go.

So what is the idea?

To build an open-source project so exemplary that people would support me by contributing code and money. Ok, maybe it wasn't the idea. It was the dream.

Fortunately, I can be realistic sometimes, so I knew I had to think of a goal I wanted to achieve that was purely in my hands (one of the learnings). Not dependent on external factors such as support or social media trending. So I decided to build a tool that can be useful for my work.

Welcome to the functions project, an open-source, curiosity-driven tool for optimizing the administration of function as a service (FaaS) technologies. Our purpose is to make it easier to build, maintain and deploy serverless functions.

A command-line tool? It sounds pretty simple, and so I thought. I will knock it off in a couple of weeks and move on. I had an idea of using it in an event-driven prototype I wanted to build in GCP shortly after. Oh, how wrong I was.

Why did you do it?

Now we are getting into the self-reflection bits. These are the best. It is where writing such an article kicks in a sense that reaches beyond simply writing stuff down.

I knew about a few points I wanted to achieve and a few I didn't know.

Knew from the start:

• Get a better understanding of the open-source world.
• Connect with an open-source community. Create your own opening.
• Learn how to build a well structured GitHub repository.
• Add a portfolio project that would best represent my characteristics and interests.

Things I didn't know I wanted to know:

• How to do a project that gets approval from a community.
• How to efficiently manage goals, expectations and available resources, such as time.
• How to do proper research on products and why that might be important.
• How to create a user story and productively use it to guide features.
• How to balance capacity, mental and project fatigue, and daily functions to avoid burning yourself out.

How did it go?

Well, it didn't go ALL according to the plan, but I got a bunch.

- Managed to deliver a project worth of issues.
- Set up a neat GitHub repository.
- Release my first Python package in PyPI. 
- Document the majority of the work and follow a decision driven development process (as much as I could).

Many of the features I initially wanted for the project were too "expensive" to consider in the first release. I had to juggle: work, willpower to finish the project and mental capacity to do so. I had to prioritise.

I am most proud of the project's scope evolution. Of the Agile practices utilised to adjust workload to the available capacity. Of the willpower it took to deliver this slightly retarded prototype.

The majority of the ideas for future development are written down, and a portion of them is even available for people to see in the roadmap.

What have you learned?

It's hard to write everything down as it comes because it can break the flow. However, if you don't, you miss out on some crucial lessons and appreciation towards the work you did, so here are a few lessons I managed to write down.

• Working on a self-driven project is a beautiful way of stimulating creative freedom of development.
• Writing documentation helps to flash out silly ideas somehow quickly.
• Writing documentation helps in getting a better understanding of the overall picture.
• It is essential to do thorough research about the "competition". Learning if someone has done anything like this will help avoid any disappointment and help you get a better sense of direction.
• It is good to have goals, but only make sure that you are not attached to an idea beyond your control, like getting paid for your work. It is a positive outcome, but it is vital to have self-driven goals in mind, like becoming a better developer or learning how to write good documentation.
• Having tests is not a requirement. It is nice to include, but it will slow the work down and risk stalling. As that it is sometimes not worth spending time on that.
• A good plan and structured work systems will help you progress with the tasks. Creating Github projects and related issues is a great of staying in a zone of the idea. The worst feeling you can have is to feel overwhelmed by the amount of work required. These help you slowly chip away from the big goal.
• As long as you believe in what you are doing, there is no need for independent validation.
• New ideas will come, current ideas will be challenged, and you will not be able to spend as much time on the project as you would like to.
• You will seriously underestimate the work required to reach a point. Not to mention there might be a global pandemic or war that might somehow influence your targets.
• Pick your dependencies wisely, or you might lock yourself in a pickle jar like I did with choosing a not developing project as the base for my app.
• Build flexibility everywhere you can (code, deployment, etc..). It can save you days of work.

Beyond such conceptual learnings, I got to try an s-ton of new tools and libraries. Here are the ones I can remember for my own reference.

# Github
Github issues and PR templates. 
Github sponsors and sponsor links. 
Github tags and releases. 
Github community standards (README, Code of conduct, Contributing, License, CHANGELOG, SUPPORT, FUNDING).

# Repo structure
Code linters and prettifiers (Black, Flake8, iSort). 

# Documentation
MkDocs - how cool is this project.
Benefits of keeping your external documentation in a separate bucket. 

# Supporting applications
Code validation with DeepSource - a muito spicy app. 
Workflow automation with `pre-commit`. 
Version and changelog automation with `commitizen`. 
Poetry and PyPI interaction in a package publication workflow.

# Code practices
Module separation, planning, naming patterns. 
File system experimentations. 
Typing journey - with mypy - has been long but promising.
Typing Stubs are a pain.  
The correct intention behind modules, classes, functions. 
Interface and type separation.

And this does not include all the unforeseen advantages of having worked with a combination of all. The chances of hearing a subject mention and geometrically connecting concepts can lead to ideas, problems being solved, and worlds being saved. Oh, the benefits of learning!

Was it worth it?

Most certainly (shouts "Hell yea!" while writing), it was. I stand stronger as a developer, ready to voice opinions and outline suggestions. Drawing on the comfort that comes with knowing how open-source projects are built. The struggles and the struggles again.

I know myself better. I know where I might stutter and where I excel. What excites me, and what topics do I usually leave for the end.

Most noticeably, I learned how to keep myself more focused and motivated when missing the creative juice—leading to more productively spent time.

Would you have done it again?

I would, and I will. I hope to work on even more exciting projects in the future, having all this experience in the background. Like with every learning, repetition is the key to success.

The first one is always the toughest and built to throw away.

So, what is next?

Honestly, I simply want to know what people think about the project.

The project will not go viral, and I knew it such as that was not its intention.

It is not necessarily about the idea, but the build process where it might be heading and is helpful to anyone.

If enough people are using this tool, I will gladly continue working on "functions" for as long as possible in the spirit of building a community.

Otherwise, I got what I wanted to acquire. I learned a lot, tested myself and built a tool that I will probably use. That is a MASSIVE win for me.

If you would like to help me keep the motivation flowing, checkout this handy way to chip in ⬇️.