4 min min read - July 25, 2014
I started to code in primary school in early 90ties. At that times the only sources of code were boring books about Turbo Pascal or C++. Bit later also magazines with a few bits of "how to write" on the last pages. Later internet came and created the whole spectrum of tutorials, but start of GitHub (and of course couple of his precursors) started tsunami of technology evolution. At the moment speed of improvements made impossible to follow. Thankfully we have amazing continuous integration tools and package managers like composer, bower, npm and global knowledge social bases like StackOverflow or Google Groups. That all combined allows you to build your solutions fast and easy without inventing the wheel. More, using cutting edge technologies like cloud computing, extreme scaling etc. comes with minimal cost. All out of the box.
But is that all just repository of good will fighters who publish their hard work to the public domain? Funny enough technology companies aren't hesitating to share their products. Yes, as publicly available, free licensed (most MIT) libraries you can use in your project. Why do they do it? What do they share? Let's check.
I base my case study on AirBnB which is both a leader in their niche and a technology leader. If you check their public github repository you can find very interesting out of the box features:
So let's face it. AirBnB shares with whole world CRITICAL elements of their DEPLOYMENT ARCHITECTURE and service MAINTENANCE. Are they crazy? Not really. That is my opinion why not:
Even having that you may ask yourself: I am doing technology startup. Can I afford playing like big AirBnB? I would answer with another question: are you technology startup or you create startup on top of technology?
If you create libraries, software components, hardware, etc. then sure, you should keep your work as your asset. If you do SaaS, PaaS you should consider playing AirBnB game. Review what is your PRODUCT and what is VALUE of it. Asses what is not a part of it and detach from your proprietary licence, but keep copyright and ownership:
More important by publishing your code under MIT licence:
you still keep ownership and copyrights to software as a result of your company work
Last and not least - you will be likely hiring talents. Many of them will come with experience and knowledge. You have to be aware that by hiring an engineer you pay for his work on specific product and on specific terms. You are not buying ownership of his knowledge and former experience. Neither you gain ownership of his work out off work. Only situation when you can defend your ownership (which still can cause more conflicts) is when this work directly violate your patents or you can prove that it is unique and designed while delivering work service. Working always on proprietary licensed can make your talents use only available solutions and never challenge technological status quo. Work is about delivering best possible labour within at least 100% of requirements, if we expect more, we need to stop thinking about that as work, but as a partnership. Always it's better to partner in public domain, than share ownership of hard to valuate a piece of code.
Hope I managed to convince you to be more open.
2 min min read - July 29, 2014
All my life I was focused on helping others to achieve their goals with my skills, knowledge and experience. That focus anyhow never made me stop to try achieve something myself. It placed me in very comfortable situation to see breaking points, rises and failures that built my believe in victory, even in David vs Goliat war. Just a couple of them:… read more…
3 min min read - July 19, 2014