Most of my software projects are designed and developed in the open and published under my GitHub username or organizations created for the purpose of the project. I believe sharing is a great asset the software industry has, and we should strive to keep it alive.
Working on open source software is not my full time job nor a source of income to me. For that reason, don't expect me to provide full-time support on those projects (I'll do my best though). I'll likely work on tasks that I find challenging or motivational.
If you would like to get involved in any of the projects or take ownership to drive them forward don't hesitate to ping me. Love for software is always welcome and encouraged.
Below you'll find the projects that I'm proud of maintaining or having maintained.
This project was inspired by this project that some colleagues developed at Shopify.
Acho allows developers to define prompts on their command line tools. With a simple interface, you can pass a list of items to the library and it'll present an interactive picker on the standard output from which the user can select one option.
I needed to execute shell tasks from some Swift libraries and tools and most of the times I ended up wrapping up the Foundation
Process providing a stubbable and convenient abstraction.
After copying and pasting the abstraction across several projects I thought it was a good idea to extract it into its own repository that could be distributed as a dependency through any of the popular package/dependency managers: CocoaPods, Carthage and SwiftPM. That's how Shell was born.
Nowadays, I use it from all my projects whenever I need some interaction with the shell. What I like the most about it is that it comes with another package,
ShellTesting that provides some handy mocks that facilitate testing subjects that interact with the shell.
This project is a Gatsby theme to add microblogging to an existing Gatsby website. It defines a convention for the structure of the posts, and provides a React component,
<Timeline/> that can be injected anywhere on the website.
It supports customizing the component used to render each post.
Before developing Tuist, I had to develop
XcodeProj, a Swift library for reading, updating and writing Xcode projects, workspaces and schemes. I debated between developing
XcodeProj as an internal component of
Tuist, or rather, implement it on its own repository and make it distributable through CocoaPods, Carthage and the Swift Package Manager. I opted for the latter.
XcodeProj is powering several other tools like XcodeGen or Accio. I'm glad that other developers found in XcodeProj the opportunity to develop their own tooling and it's exciting to see all the ideas they come up with.
I started building Tuist back when I was at SoundCloud. We embarked on the journey of modularizing the codebase to speed up builds and make the teams atomic. Maintaining a modular Xcode project is cumbersome so Tuist was my answer to make the work more convenient.
One of project's main principles is enforcing conventions over configuration. We are taking the opportunity to make simple what it's not straightforward in Xcode, like configuring dependencies and their transitives. The goal is to remove all the maintenance burden from the developers and let them focus on building great apps.
Despite it's not a project widely adopted, nor have I had the opportunity to use it myself (because I don't do much development with Xcode these days), we continue to move steadily with the help of talented maintainers and contributors.
It's one of the open source project that I'm most proud of because of the value it provides, the quality of the code and the tests suite, and the people around it.