summaryrefslogtreecommitdiffstats
path: root/_build/content/articles/on-open-source.asciidoc
diff options
context:
space:
mode:
Diffstat (limited to '_build/content/articles/on-open-source.asciidoc')
-rw-r--r--_build/content/articles/on-open-source.asciidoc137
1 files changed, 137 insertions, 0 deletions
diff --git a/_build/content/articles/on-open-source.asciidoc b/_build/content/articles/on-open-source.asciidoc
new file mode 100644
index 00000000..6e700e8a
--- /dev/null
+++ b/_build/content/articles/on-open-source.asciidoc
@@ -0,0 +1,137 @@
++++
+date = "2014-09-05T00:00:00+01:00"
+title = "On open source"
+
++++
+
+Last week I read a great article
+http://videlalvaro.github.io/2014/08/on-contributing-to-opensource.html[on
+contributing to open source] by Alvaro Videla. He makes
+many great points and I am in agreement with most of it.
+This made me want to properly explain my point of view with
+regard to open source and contributions. Unlike most open
+source evangelism articles I will not talk about ideals or
+any of that crap, but rather my personal feelings and
+experience.
+
+I have been doing open source work for quite some time.
+My very first open source project was a graphics driver
+for (the very early version of) the PCSX2 emulator. That
+was more than ten years ago, and there
+http://ngemu.com/threads/gstaris-0-6.30469/[isn't
+much left to look at today]. This was followed by a
+https://github.com/extend/wee[PHP framework]
+(started long before Zend Framework was even a thing) and
+a few other small projects. None of them really took off.
+It's alright, that's pretty much the fate of most open
+source projects. You spend a lot of work and sweat and
+get very little in return from others.
+
+This sounds harsh but this is the reality of all open
+source projects. If you are thinking of building a project
+and releasing it as open source, you should be prepared
+for that. This is how most of your projects will feel like.
+Don't release a project as open source thinking everyone
+will pat you on the back and cheer, this won't happen. In
+fact if your project is a too small improvement over existing
+software, what many people will do is say you have NIH
+syndrome, regardless of the improvement you bring. So you
+need not to rely on other people in order to get your
+enjoyment out of building open source software.
+
+In my case I get enjoyment from thinking about problems
+that need solving. Often times the problems are already
+solved, but nevermind that, I still think about them and
+sometimes come up with something I feel is better and then
+write code for it. Writing code is also fun, but not as
+fun as using my brain to imagine solutions.
+
+You don't need thousands of users to do that. So are
+users worthless to me then? No, of course not. In fact
+they are an important component: they bring me problems
+that need solving. So users are very important to me.
+But that's not the only reason.
+
+I got lucky that the Cowboy project became popular.
+And seeing it be this popular, and some of my other projects
+also do quite well, made me believe I could perhaps work
+full time on open source. If I can work full time then
+I can produce better software. What I had one hour to
+work on before I can now spend a day on, and experiment
+until I am satisfied. This is very useful because that
+means I can get it almost right from the beginning, and
+avoid the million API breaking changes that occured
+before Cowboy 1.0 was released.
+
+To be able to work full time on open source however,
+I need money. This is a largely unspoken topic of open
+source work. The work is never free. You can download the
+product for free, but someone has to pay for the work
+itself. Life is unfortunately not free.
+
+Large projects and some lucky people have their work
+sponsored by their employers. Everyone else has to deal
+with it differently. In my case I was sponsored for a
+while by the http://leo-project.net/leofs/[LeoFS]
+project, but that ended. I also had the Farwest fundraiser,
+which was a success, although the project stalled after that.
+(Fear not, as Farwest will make a comeback as a conglomerate
+of Web development projects in the future.) After that I set
+up the http://ninenines.eu/support/[sponsoring scheme],
+which I can proudly say today brings in enough money to
+cover my food and shelter. Great!
+
+This is a start, but it's of course not enough. Life
+is a little more than food and shelter, and so I am still
+looking for sponsors. This is not a very glorious experience,
+as I am essentially looking for scraps that companies can
+throw away. Still, if a handful more companies were doing
+that, not only would I be able to live comfortably, but I
+would also be able to stop worrying about the future as I
+could put money on the side for when it gets rough.
+
+A few companies giving me some scrap money so I could
+live and work independently is by far the most important
+thing anyone can do to help my projects, including Cowboy.
+Yes, they're even more important than code contributions,
+bug reports and feedback. Because this money gives me the
+time I need to handle the code contributions, bug reports
+and feedback.
+
+If Cowboy or another project is a large part of your
+product or infrastructure, then the best thing you can do
+is become a sponsor. The second best is opening tickets
+and/or providing feedback. The third best is providing
+good code contributions.
+
+I will not expand on the feedback part. Feedback is
+very important, and even just a high five or a retweet
+is already good feedback. It's not very complicated.
+
+I want to expand a little on code contributions
+however. Not long ago I ran across the term "patch bomb"
+which means dropping patches and expecting the project
+maintainers to merge them and maintain them. I receive
+a lot of patches, and often have to refuse them. Causes
+for refusal vary. Some patches only benefit the people
+who submitted them (or a very small number of people).
+Some patches are not refined enough to be included.
+Others are out of scope of the project. These are some
+of the reasons why I refuse patches. Having limited
+time and resources, I have to focus my efforts on the
+code used by the larger number of users. I have to
+prioritize patches from submitters who are reactive
+and address the issues pointed out. And I have to plainly
+refuse other patches.
+
+I believe this wraps up my thoughts on open source.
+Overall I had a great experience, the Erlang community
+being nice and understanding of the issues at hand in
+general. And if the money problem could be solved soon,
+then I would be one of the luckiest and happiest open
+source developer on Earth.
+
+Think about it the next time you see a donation button
+or a request for funds or sponsoring. You can considerably
+improve an open source developer's life with very little
+of your company's money.