Share your code, make it open source
Any developer has most probably made use of a third party library at some point on their career but not many of them have even considered writing one themselves. They might think what they do isn’t good enough, not well coded or even useless to someone else’s purpose. Nothing further from the truth. In this post I’m gonna tell you about our experience releasing our first Open Source Mobile Framework at ElConfidencial. You can find it here for iOS and here for Android.
Why would we think of creating our own library?
At ElConfidencial we follow Scrum and, truth be told, my Product Owner (PO) and good friend, Juan, is quite picky and is often telling me about design patterns and solutions other great Apps implement. He wanted something very specific and unique as a walkthrough or show case for new features we were to release in future versions and this is how it all started.
Honestly, I first started by googling “show case”, that’s what every good developer would do. My mom would call me lazy for that, I just applied one of my favorite principles in programming: KISS (Keep it simple, stupid). This is actually meant for new features: don’t try to foresee the future, just meet your requirements because, as Clint Eastwood would say in The Bridges of Madison, “tomorrow is promise to no one”. The same way we could extrapolate this principle and use it here: if there’s something out there that works, it’s tested and it’s free to use, why would you take any time on doing it yourself, “stupid”? We could come up with a couple of reasons:
- There’s nothing similar to what you’re looking for.
- You cannot customize the library you found to meet your PO expectations.
The latter was our case. The results in Google showed me my PO wouldn’t like the options I’d give him and most importantly: the cost of developing this library was assumable for us.
What made us even think of releasing it?
When I saw the face of my PO in the Review that Friday when we showed him the result of that Sprint I knew we’d done a wonderful work. And I don’t wanna sound cocky or bragging but we had.Don’t misunderstand me, it’s good to be conscious about your own mistakes… but also about your successes and we were very happy with the results. So happy I’d say that, why not, we thought of making the library public.
Was our framework better than the ones already in the market? Probably not. Was it clean code that we published, fully tested and had high performance? Let me doubt about it.
Why did we still publish it? We were proud of ourselves and we had something that was different from other available products. We’d been always using others’ code and we wanted to contribute to the community, that’s the goal of all this, right? The same way we’d been making use of third party libraries, others might find ours interesting and use it in their projects. But most importantly: we wanted to improve our skills as developers. Hearing from other developers feedback would help us face new issues, improve the product as well as achieve new knowledge.
Have some code that might be useful to others?
Here are some steps to follow if you wanna publish it. The first thing to do is refactoring your code, making it clear to the rest. This isn’t just about releasing a first version of your library and forgetting about it: other developers might want to contribute and pull request your repository so making it legible and easy to understand isn’t such a bad idea. As Uncle Code would say, there’s no better documentation than the code itself. Extract new methods and classes, rename variables and functions, avoid repetition of code… You probably know what I’m talking about if you’ve happened to take a look at Clean Code. However, even if your code is pretty understandable… comments will kill nobody if they’re useful and constructive.
Get Fernando Moya de Rivas’s stories in your inbox
Join Medium for free to get updates from this writer.
But wait, how will your prospective users know how to use it? Will they read the large documentation you’re preparing for them? Speaking for myself, I always try to find a quick example to follow and then rely on the usual hotkey most IDE’s have: control + space. This usually shows some quick documentation about the public methods and properties of the class. So how does this work? Is this magic? I’m sure you’ve heard about javadocs or any other kind of markdown. Most languages have their own and it’s basically a set of “escaping expressions” contained in a comment that an IDE knows how to interpret. For example, below I’m describing the class constructor and its parameters as well as remarking some requirements for the parameters:
The next step is to create a git repository and share your code, make it public. The most widely used repositories are GitHub and BitBucket. I personally use the former for personal projects and public repositories whereas I use the latter for private ones so you’ll most probably end up using GitHub.
Besides the repository, you’ll need to add several extra files to your project in order to provide meta information about your repository. The first one is a LICENSE file which is usually requested when creating a repository in GitHub. Wait, a license? I don’t know anything about the current legislation.
Don’t panic, a LICENSE file is just a formality. Here’s a good resource to help you understand why you need a license and what’s the best one for your project. The most common licenses are MIT and APACHE.
Once you’ve chosen the most appropriate one for you, it’d be a good idea to add a README. A README is the file where you’ll explain what your framework does, why it is so special, which features it provides you with and how it works. Basically, it’s like a quick introduction to your framework. And guess what? It uses its own markdown language! There’s a good tutorial about it here. Additionally, it’s very common to complete this file by adding badges that describe certain aspects of your project like the last version, support, … Take a look here.
You won’t usually need a very extensive documentation but if that’s the case, you might want to take a look at the Wiki option of your repository to structure your API in sections.
Optionally, there’s an extra file you can add which is the CHANGELOG file. This helps developers know about new features and fixes to bugs that new versions of your framework introduce. This is optional as I said but it usually gives you more visibility in a package manager repository. Hold on, is there more about it? What’s a package manager repository? Well, you have so far done the hardest part: you’ve developed a framework, you’ve generated an API and documented it, you’ve uploaded your project to a public git repository… nonetheless, how’s anyone going to use it? Are they suppose to just download it and manually install it? I mean, that could be an option… but that’s not elegant at all. That’s why there are different places depending on the platform you’re coding for where you can find stored thousands and thousands of third party libraries which you can easily reference by means of a simple file, such as pod in CocoaPods and pom.xml in Maven. These two platforms are actually package managers which allow you to quickly install in your project any library you might need.
You should try to support as many package managers as you can. After all, you’re trying to get to as many users as possible so it makes sense your library shows up in the more package managers the better.
Last but not least, marketing comes to play: you’ll need to let developers know about your product. No one will use it if they don’t know it exists, so use everything in your hand to make it visible:
- StackOverFlow is a must. Your product will probably answer some other developer’s question.
- Blogs. Again, depending on your platform you’ll need one or another. We used Android Arsenal to advertise our Android version.
- Social Networks. No, I’m not talking about Instagram or Snapchat… although you might be surprised. I was actually talking about LinkedIn. Everyday I read a bunch of articles about other people’s projects and experiences so I guessed a mention to this achievement of ours in my wall would perfectly fit.
- This blog itself, Medium. After all, if you’ve come so far you’ve probably got a good idea about what we’ve done and isn’t that the purpose?
Conclusion
You should not be afraid of sharing what you’ve coded as the feedback you’ll get will just help you improve your code your product while making other developers lives easier. You’ll also learn about the experience.
The steps to release your framework might seem tough but it’s a once-in-a-lifetime thing that will give you more credit as a developer and help you in your career.
