diff --git a/_posts/2015-09-08-firefox-os.md b/_posts/2015-09-08-firefox-os.md
new file mode 100644
index 0000000..fff2350
--- /dev/null
+++ b/_posts/2015-09-08-firefox-os.md
@@ -0,0 +1,34 @@
+---
+layout: post
+title:  "My Experience Developing an Application for Firefox OS"
+date:   2015-09-08 02:06:00
+permalink: firefox-os-development-experience
+categories: experience, firefox-os
+published: false
+---
+
+So, I made my first actual product, Hawk. It all started by installing Firefox OS on my Nexus 4 just to try it out.
+
+I searched Marketplace for essential apps I would install on Android, well,
+a File Manager is necessary, I found [this](https://github.com/elfoxero/file-manager) which is good but it lacks a lot.
+
+I was wondering if I could write a File Manager–creating was not my only intention.
+I thought I would use React Redux stack and learn it on the way.
+
+So I did, I wrote a File Manager which I personally think looks good and has good functionality (I have a lot of ideas to be applied).
+I learned React Redux, too, in my opinion it's a good pattern but I think some parts of it can be improved further.
+
+Anyways, I'm here to talk about my experience writing a Firefox OS Application.
+
+*TL;DR: You feel right at home, debugging tools are great (WebIDE), but a little buggy sometimes.
+You can use latest web features without worrying about cross-platform and these shits. The overall OS performance is lower than expected.*
+
+#Home, Sweet Home
+Writing mobile applications using Web technologies without having to worry about *porting* things,
+banging your head against old webkit's weird behaviors and compatibility issues with old devices (looking at you, PhoneGap) feels great.
+
+One thing I really like about Firefox and Firefox OS is most new and spicy JavaScript features are supported and you don't have to prefix anything.
+Although I think performance of CSS animations/transitions can be improved on Firefox (they're faster on Chrome I think), you won't have much problem
+writing applications for Firefox OS, I used a lot of transitions and animations in my application.
+
+#Tools
diff --git a/_posts/2015-10-13-open-source-good-bad-ugly.md b/_posts/2015-10-13-open-source-good-bad-ugly.md
new file mode 100644
index 0000000..1b279b0
--- /dev/null
+++ b/_posts/2015-10-13-open-source-good-bad-ugly.md
@@ -0,0 +1,85 @@
+---
+layout: post
+title:  "Open-source: The Good, The Bad, The Ugly"
+date:   2015-10-13 06:15:00
+permalink: open-source-good-bad-ugly
+categories: experience, open-source, opinion
+draft: true
+---
+
+I have been doing Open-source for a while, I don't call myself an "expert" or something like that,
+but I'd like to share my opinion on contributing/maintaining open-source code.
+
+So, I've been following and contributing to open-source projects for quite a time,
+and I have had different experiences each and every time. There always are good experiences and bad experiences
+along a road, it's never a heaven, never a hell. I've had contributions as small as fixing a typo in README, or as big
+as adding a new feature to Firefox Developer Tools or refactoring a whole repository!
+
+Here I'm going to share my experiences and what I've learned along the way that you should consider
+if you want to take this road.
+
+The Good
+--------
+
+I love open-source, it's awesome how people share their efforts with others, and others give feedback to
+the maintainer to make the software better. It's an always-growing system, even if a maintainer stops maintaining,
+it's possible to _fork_ a repository and continue it, although not as easy, but possible.
+
+The best part of doing open-source, in my opinion, is building connections and learning from others.
+
+Whether you are maintaining or contributing to a project, you are going to learn new things, it just happens.
+
+If you are a maintainer of a repository with a countable amount of users, you are going to constantly learn your mistakes from others,
+finding these mistakes by yourself is really hard, because you can't easily look at a subject _the other way_,
+but users have this potential to look at your code with their eyes, seeing mistakes you can't see.
+
+If you are contributing, following or just exploring projects, you are definitely going to learn from the events in project, the solutions people suggest to a problem,
+the way they communicate, etc.
+Usually, not always, the maintainer has a better knowledge over the subject of project than you, so you are going to learn from him and other contributors
+by reading their code or exploring the issues and how they've been solved. I personally learned a lot this way. I would volunteer to fix a bug, then the maintainer and other contributors would show up to give their suggestions and ideas on the issue, which I would learn from. I also subscribe to interesting issues that I don't know how to fix to see how they get solved.
+
+The Bad
+-------
+
+First off, the most annoying thing about open-source contributions is that people (I'm looking at you, maintainers) think
+that contributors are jobless bored people who don't know how to spend their time and have come to waste some time on some random open-source project, NO, seriously.
+
+I have a job, I totally care about my time and I'm not making a Pull-request because I'm bored.
+
+Now, why is that important to know, it has happened to me a couple of times that I ask on an issue:
+
+_"- Okay, I'm interested, what **exactly** has to be done?"_
+
+_"- Great, please do x, y, z"_
+
+_... some time later_
+
+_"- Here is x, y and z, please review and merge"
+
+_"- Oh, thank you very much, but you know, now that I think of it, I don't want x, y or even z. Closing."
+
+and I'm like:
+
+![Are you kidding me?](/img/are-you-kidding-me.jpg)
+
+{% include 'caption.html' text='Are you fucking kidding me?' %}
+
+This is the worst thing that can happen to you, try to avoid it, you don't want your valuable time wasted.
+
+How to avoid it you ask, there is a sign that I've found which leads to this problem most of the time and that's **lack of clear specification**, just like with clients, if the maintainer doesn't specify what should be done, you should stop.
+
+It happened to me, just like the past discussion, except he didn't tell me _"Please do x, y, z"_, he made himself look
+too busy and said: _"The title says it all"_, no, it doesn't say it all. "x, y and z" can be implemented in `2^9` ways, and sadly,
+you are not going to accept the `192`th way, as you "don't like it". Do not get trapped in these time-wasting situations, I wish maintainers understand how valuable peoples' times are.
+
+The Ugly
+--------
+
+The sad part about open-source is, if the maintainer decides not to support the project anymore,
+people will _kind of_ suffer. If the maintainer abandons the project, the project is *almost* doomed, as forking and continuing is really hard, reading the code from bottom up and understanding it isn't easy, and as there is no outcome, people usually decide to abandon a project once they lose interest in the topic.
+
+If I personally lose interest in a project I've made, I'll abandon it, I will try to guide new users through but I usually
+don't offer as much support, I have more important things to do, it's really sad, but true.
+
+To prevent this from happening, you must be able to make money out of your project, or your project must be really interesting
+and challenging to keep you working on it.
diff --git a/img/.DS_Store b/img/.DS_Store
index 5008ddf..d0eb48a 100644
Binary files a/img/.DS_Store and b/img/.DS_Store differ
diff --git a/img/are-you-kidding-me.jpg b/img/are-you-kidding-me.jpg
new file mode 100644
index 0000000..ec323d9
Binary files /dev/null and b/img/are-you-kidding-me.jpg differ