After 15 years of working as developers of ecommerce sites, we decided to share our know-how and experience using open-source software. Nowadays there are many examples of projects which had adopted this approach from the start, and by and large have been very successful.
However, moving from closed-source to open-source after 15 years is no easy task, and requires a lot of preparation and work. At the same time, we believe it’s the right way to go and today we’ll tell you why. By the end of this article, our hope is that you’ll have a better understanding of the benefits of open-source platforms why you should consider this approach for your next project.
1. The Best Developers Want to Share Their Ideas
A few months ago we held the 5th PHPLive conference in Žilina, Slovakia, where we also had a very interesting panel discussion with 5 developers (Nikol Ježková, Miro Stopka, Tomáš Votruba, Tomáš Pilař, Jan Mikeš ). The topic of the 20-min discussion full of energy and ideas was “why open-source projects beat closed source”.
Miro Stopka shared his point of view and was proud that his work was able to be seen on Github (at the time the official public release was still 2 months away). When we asked the audience if they’d prefer working in a company that had adopted an open-source style compared to a closed-source, over ⅔ raised their hands! 67 %! We expected around 20–30 %, but not 67 %!
It’s natural that people want to share their work and be acknowledged for it. Designers share the website they created in InVision, professors and doctors share the results of their experiments in research papers, and writers share their books on Amazon. And developers… well, no-one can see their actual work. They might work in a popular company for a number of years, but all they can show for it is an additional line on their LinkedIn profile. Ask any developer, and they’ll be familiar with this frustration.
Thanks to open-source, however, developers are publicly known for their skills.
Do you want the best developers to come to you? The solution is to find a way to ensure their skills are recognized and shared.
2. It’s The Way The World Goes
Many of you already know open-source from companies like Google, TensorFlow, Facebook, React… big names that are globally recognized. But there are examples even closer in Central Europe: Apiary — Dredd, LMC — Steward or Slevomat — Coding Standard.
All these companies have the best developers who actively share their know-how with the world, and can always reference these projects (or even specific commits) when they leave.
“Be the change you want to see in the world.”
Even proprietary code pioneers like Windows or Apple understand this very healthy trend. For example, Apple released its first open-source project Swift in late 2015 and Windows also came through with its tolerant-php-parser.
Do you have a code you’re proud of and could help others? Then switching to open-source may be the right choice to help you spread the word.
3. Allow Experts From All Over the World to Consult Your Project
The best open-source developers who are rising stars in the industry have a natural passion and desire to contribute to the Github community. They enjoy the challenge of improving projects on Github, even if they know they’ll never use them, simply because they have the expertise and willingness to test their own skills. A prime example of this is Gabriel Caruso who managed to contribute to 18 various PHP projects in the last half of 2018. Think of the potential here: of the 2020 commits he made over those 6 months, 100 of them could have been in your project. And that’s just one PHP programmer.
Same reason as above, developers also love to have their work shared and Github is one of the only (and probably most popular) ways to get such credit.
Thanks to developers like this, you don’t have to hire expensive lectors for 2 days of private lectures. Just let your developers manage Github issues, pull requests, and collect feedback from the community around your project. You’ll soon see that your team is much more advanced because of the various interactions and cooperation with open-source developers.
How can expert PHP developers improve your code if they don’t have access to it?
4. What About Business?
Let’s look at things from the business perspective. You attract the best developers there are, you give them credit and attribution for life, you make people happy and your product is attractive because you share it for free…but how do you balance this against making profits?
First, a better developer makes you more money than a bad one. Exponentially more. For example: a bad developer works with a database and he heard about ORM, so he makes one from a layer above mysql. It will take 200 hours just to create it and after 2 years he leaves your company with all the legacy code, which may be hard to read by the person who takes over. The better developer uses Doctrine ORM, which will take a maximum of 10 hours even if he or she never heard of it, and when they leave another Doctrine developer can easily replace them.
And that leads us to…
5. Common Knowledge Makes Easy Adaptation
…and easy adaptation to a new project makes hiring faster.
Imagine an average PHP developer who works with Symfony and Doctrine for the last 3 years and has 2 job offers to consider:
- $ 50 000 a year, PHP company, e-commerce selling shoes, closed source, they claim they use PHP 7.1 and “modern technologies”
- $ 45 000 a year, PHP company, e-commerce selling shoes, open source, they use Symfony 3.4, Doctrine 2.6 and PHP 7.1 which you can check on Github
Which one do you think they’ll pick to work with? And what happens if the second job offers even more money to match the first offer ($50 000)?
By being open about your skills, and conveying both your strengths and weaknesses, you’ll attract developers:
- who understand your code,
- who believe they can be a useful addition to the team
- and see that can learn from you.
And all this with zero expenses for job promotion, marketing, or even meeting the developer. If “a picture is worth a thousand words”, then:
“Github repository of your company is worth 100 job interviews.”
6. Open-Sourcing as The Next Level of Code Maturation
You have different standards on yourself while giving a talk in front of 100 people than you have with a close friend in a loud pub. It’s a rough attribution, but for the code, similar rules apply.
In Shopsys 5 we had low test coverage, no Docker, no coding standards, no CI, no documentation, our own framework, monolith architecture, and plenty of legacy code. To be honest, it wasn’t all that bad, and we had some tests.
But when we knew we’d have to migrate to Symfony Framework in Shopsys version 6, we naturally started to feel a bit ashamed. How accessible would it be to others? What are the standards in PHP nowadays? What would contributors be looking for? For our own staff, this wasn’t a big deal since we specifically trained each one for several weeks after hiring them.
But what would be needed to ensure that someone who only had 30 minutes to look at it would not only be able to understand it fluently, but also feel inspired to work on it?
As a result, we decided to focus on:
- PSR-2, PSR-4, PSR-11, PSR-3 etc. standards integration
- Coding Standard across the whole company
- Smoke Testing of all controllers
- Docker containerization to get installation times down from 8 hours to 30 minutes
- Un-written standards
- Moving all custom code that seemed useful into commonly used public solutions — e.g. from own class loader to PSR-4 composer autoload
- Moving proprietary code to Symfony
- From monolith to decoupled code
- From many various packages to 1 monorepo
As well, we underwent a number of other transitions as we moved from legacy to open-source, the technical details of which we’ll cover in the next post.
If Shopsys Framework had remained closed-source, it’s likely it would have taken us another decade to get to where we are, and we would still be stuck with our proprietary framework.
We believe that by open-sourcing, the standards on the code increases substantially.
Baby Steps
Today we gave you 6 reasons to migrate from a closed to an open-source project. It’s not an easy journey, but we are encountering new reasons for making that transition every month. We know it takes great courage and more than a little faith, but are fully committed to embracing open-source as the primary solution for online stores and software development. Stay tuned as we bring you more posts on this topic.
Do you want to cooperate on an open-source project? Our long history of working with clients speaks for itself, so take a look at our Github repository, and if you like what you see and think you’d enjoy working on it and helping us improve, let us know.
We’re still learning and are excited to work alongside those who can help us make Shopsys better.
