The rumors have finally been confirmed. Docker, Inc. is opening their new R&D center in Sofia. At an event last night, they stated their intentions to do a fair amount of product development in Sofia as well as contribute to the local society/community too (if I got this correctly). This is very good news for the local eco-system so congrats for that from my side!
This blog post outlines my impressions from the event and a few related more general thoughts.
How did Docker came to Sofia?
I don't know the details but their top team in Bulgaria seems to be coming directly from VMware. So were other engineers present at the event who are based elsewhere. When you think about it this is not surprising at all. (FTR VMware is also directly responsible for having Uber engineering in Sofia).
VMware is one of the few companies in Bulgaria that does real product development and R&D (credit where credit is due). There's even a smaller number of companies developing infrastructure products, e.g. the same things I test on behalf of Red Hat. The majority of the other companies are either outsourcing or focused on products in upper layers of the stack!
Contributing to Open Source according to Docker (and myself)
This BoF session was lead by Andrew Hsu and Sebastiaan van Stijn. The group was predominantly inexperienced in terms of OSS contribution but motivated to try/find a project where they can contribute. From what I could tell they were relatively experienced software engineers.
On my question "what are they planning for the local community in Sofia?" the immediate answer was meet-ups and presentations which is expected. This is how you start and try to establish the level of experience of the local groups and their level of interest in what you are doing.
I prompted a bit further about workshops or hackathons and they told me they've had a hacking even in Paris but didn't elaborate much further. Maybe it is too early for them to be able to give more detailed answers. Let's hope we'll see more practical events.
Andrew did outline the general principles of their community (aka don't be a jerk), pointed out the various communication channels they have (rip IRC), the fact that internally the company uses GitHub and encourages cross-team participation via the pull request workflow. This is what my friends at Bitergia call "inner source" and is a good thing!
A few of the participants asked how and where to start and all I kept hearing was "follow pull requests on GitHub", "do you want to see some source code"! This is something I take issue with so let me explain.
While that has been the historical model for doing open source, aka dig straight into the problem, and also how I started and still do open source I think it doesn't work in the modern world. What I've seen from my students and folks which I've trained is that they have far too many opportunities to be bothered to dig deep into something which seemingly puts roadblocks on every step of the way. Especially when you are a new comer. I myself experience this regularly and often get frustrated by communities who make it damn nearly impossible to land a code change. My only motivation here is that I depend on that component being fixed and there is no work-around.
To be fair to Docker our Fedora or Red Hat communities aren't much better in this regard. In most of the projects I've contributed they kind of expect you to be motivated enough and be able to figure out both process and technical details mostly on your own! Maybe it is the nature of working on platform and infrastructure. You do need a fair bit of general knowledge and specific system knowledge to work on such projects.
My personal experience leading Kiwi TCMS has been that most contributors need a long time to settle in and feel comfortable in the project and that they do need a fair amount of hand holding.
First and fore-most many contributors don't know the underlying technology well enough. For complex software there's also the whole issue of computer science 101, operating systems, how the kernel or virtualization engine works, etc. Then you need to know the architecture of the software you want to fix, the libraries and frameworks it uses - this helps you quickly navigate to the place which needs a patch. Honestly this takes years to master and to develop a gut feeling about it. On the outside it may look easy because active contributors have had many years of experience acquiring this knowledge.
Then we have the "process" part. How do I open or rebase a pull request. How to amend commits, etc. This is something I learned the hard way but I've shown it to other people and they were able to advance much more quickly. Also things like how do you communicate with others in the community, how do you "push" for some types of changes, etc. Dedicated mentors will help a lots here, but that also means dedicated contributors.
We do provide a detailed technical training and on-boarding program and mentoring for Kiwi TCMS and still there are more people who give it a try and drop out compared to those who stay with the team. We still expect commitment and finishing the tasks one set out to complete though.
My initial impression (from Docker) for the moment is very guarded and mostly critical. I feel like they are interested in finding folks to contribute to their own repositories and then hire them (that is expected) but I don't feel like they care much about what happens outside their own projects. I hope I am wrong and we do see engineers (regardless of who employs them) contributing all over the place on a regular basis.
What is the problem ?
The problem for the local eco-system (and it is a world wide problem) is that there are many companies coming in but there is a very limited pool of talent. Especially in less popular fields like research, operating systems and low level infrastructure. That takes many years to develop in house and to reach critical mass for a thriving community. I don't feel we are there yet!
In a later blog post I will describe the history of ScyllaDB which is the measure of success I would like to see in Bulgaria.
The problem I see for the open source community (in the country) is that nobody is really working on developing that. There are small efforts by individuals or a few companies but the mechanics of open source and the culture of free sharing of knowledge is something I don't see yet. I fail to see a program, like Google Summer of Code perhaps, where developers are encouraged and supported to contribute just for the sake of contributing.
Also I fail to see a structure which will help new contributors and young developers set out on a path of meaningful contributions early in their career and by doing this improve their skills and personal brand which ties in with the first paragraph.
These are some things I have observed and some gut feelings from someone who's been doing open source for 15+ years. I can't pin point exact reason why this is happening. I don't have a recipe how to fix it!
I do however keep in touch with like minded folks from several other companies and we've discussed these topics occasionally. We do have some ideas but lack critical mass, shared goal and self-organization.
Comments !