I would like to share with you my own opinion on why I initially joined Petr Hráček in pursuing the idea of a portal for developers running Fedora and why I think that this project will help new and existing developers to take advantage of everything Fedora Workstation has to offer.
Let’s start from the beginning. I was actually a Mac OS user and an occasional PHP and Ruby developer before joining Red Hat and becoming a co-maintainer of Ruby and Ruby software on Fedora and RHEL. If you happened to be in a similar position you understand that I had no clue that someone even repackage upstream gems from RubyGems.org and, in a more general way, that some operating systems offer more then just core utilities and a few desktop applications. There were a lot of times I struggled with installing some gems with C extensions and often found myself just googling for a quick solution. Or used Homebrew (as every developer on Mac) trying to get some software installed and prayed for an easy install without conflicts and compilation errors.
On Fedora one can solve it easily by installing the associated package. Packaged software is not only nice on server and for administrators, but they are nice for developers as well. Fedora has a lot of packages, but developers don’t know about them. Or they know about them and avoid them for no specific reason. I have seen a lot of blog posts or comments suggesting not using system versions of Python or Ruby. But why really?
Yes, on CentOS 6 there can be an old version not supported by upstream anymore, but on a recent Fedora? We have Ruby 2.2.2, we have Python 3.4.2. And still many people don’t use them. They think that those packages are here only for supporting other software in the distribution. But I beg to differ. We spend a lot of time packaging the software and we work hard to make sure these runtimes work smoothly on Fedora. We often have patches that fixes pain problems including security patches. So why shouldn’t be these packages used by developers is what I don’t get.
Sometimes you just want to try the software out. There might be new and existing stuff that you want to try out like Elixir language or Express framework for Node.js. And you wouldn’t guess that both are packaged and available on Fedora, would you? And that perhaps there could even be a DevAssistant’s assistant for some of them that let’s you start your new project with a single command in your shell — be it a Flask app in Python or GTK application in Vala. And yes, I fully understand that some would still prefer to get the software from upstream. Or that they need to, because they want to use the latest features that are in a pre-release version.
But Fedora still offers that as well. It just offers a lot of stuff packaged, tested and ready to be installed and managed by DNF which enables you to easily track and manage all components on your system. I think we can agree that this can be very beneficial especially for new-comers. If you want to try out Ruby, you don’t need RVM. To learn a new language/framework/database you don’t need to introduce another intermediate program that you don’t understand. You just want to start writing code and run it. I personally don’t want to download a tarball, extracting it somewhere and set up correct paths before I can try out how callbacks work in Node.js. And I don’t have to on Fedora, which is great.
Another thing I was working on was getting Vagrant with libvirt support to Fedora. One thing to prefer libvirt over VirtualBox is that libvirt is available on Fedora by default and so that we can have even better experience of installing Vagrant than anyone else. Running dnf install vagrant-libvirt is simpler than installing upstream package (even if offered as RPM) and VirtualBox separately. In case you would actually want to use libvirt provider with the official Vagrant package, you might run into problems with C extensions or something else and spend a day figuring it out before you start to work on the thing that’s really important for you — your own project (Vagrant uses RubyGems for plugin installation so the same problem of gem installation applies). And that’s only another example of what Fedora can offer developers.
But having said that… How do you know that we package Vagrant in Fedora? How do you know that you need to install vagrant-libvirt package to get the libvirt support? How do you find out that we changed a default provider? How do you know that your Ruby is not broken, but just packaged in a way that dnf install ruby won’t give you the same Ruby as upstream? Why is it recommended to install perl-core? How do I know that I should install postgresql-contrib to use hstore or separate postgis package to have Postgis extension available? How can I know that my Fedora already comes with Python 3? So many questions and no simple answers… perhaps until very soon.
So when I have seen this idea, I was on board. Having a great distribution with great packages is not enough if people out there don’t know about it and if they don’t know how to use these packages. So getting better at documenting this is a key. Yes, it could live in the documentation or in the wiki. Perhaps ideally that would be sufficient. But developers on Fedora don’t use them. Look at our wiki — it’s too focused on contributing to Fedora.
Having a specific place for developers would not only increase the documentation standard of these packages. I am sure it will help attract many people outside of the community to actually come and try Fedora. They will see how many things are pretty easy to accomplish on Fedora and that a good developer experience is one of our goals. It will help us to market Fedora better and I believe we should at least try.
The good news is that we actually started to work on it already and its first version should be out rather soon. That would also not be possible without other people joining us and contributing. So thanks Adam Šamalík who joined us in leading the efforts of getting this project bootstrapped and running, Máirín Duffy for the design and Fedora developers who contributed some content.
Read more about the upcoming developer portal on Adam’s blog or Fedora wiki and see our GitHub pages (more on the technical details later). And please get yourself involved in the project, we are waiting for you!
