ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
Not all licenses are created equal
IANAL. As you are all are hopefully aware there are huge differences the exact "freedoms" allowed by the various open source licenses. I find that many younger developers have a natural affinity to the GPL, because they seem to feel its important to prevent someone from just taking their code, building upon it and not releasing their changes under an open source license when they distribute. Maybe with enough experience you start to realize that it happens close to never that a proprietary fork of an open source project ends up outpacing the original project. So why bother regulating this? It just makes legitimate business uses harder and in the grand scheme of things, I don't worry about this. People who prefer to go proprietary are likely not in the state of mind yet where I would want to work with them anyway.
My take on the MicroPHP manifesto buzz
Ed's recent blog post labeled the The MicroPHP Manifesto got a lot of attention. Personally I feel like Ed's way of expressing himself feels mostly like the rants of an angry person and not really a way of expressing a clear message. That is why I appreciate a much saner formulated follow up by Kris Jordan. In general I totally agree with Ed on the point that we need more decoupled components in the PHP world. The timing seems a bit odd since exactly that seems to be an emerging trend with all the various libraries cropping up since PHP 5.3. Where he looses me is with his seeming obsession with LOC minimization. It sounds to me like he assumes that any 3rd party code he pulls in, he automatically also has to maintain. To me that seems a bit odd. Obviously any 3rd party lib might contain bugs, which one might need to debug. But when choosing a 3rd party lib I focus on seeing if I trust the development team. I apply metrics such as track record, existing tests and documentation (oh and don't forget license). And of course I also browse the code and the response time and attitude in the bug tracker. If I hit an issue I do expect to be able to fix it myself if necessary, but in most cases I will just do my best to file a bug report with steps for how to reproduce the issue. Obviously being somewhat known in the PHP community for doing my share, I might be getting slightly better response times than most devs. But I still do not see how LOC in a 3rd party lib need to be a criteria for how hard it will be to maintain said dependency.
.EU PHP company knowledge exchange
For now I am limiting this vision to just European companies. But the idea that is materializing is for PHP companies to train each other on technology or processes related to their daily business. Liip today received a remote training by Konstantin from KnpLabs on Behat. In January David will give a training for KnpLabs on behalf of Liip about the Symfony2 CMF. For now this will happen remote (we still need to figure out a better setup), because this all happened fairly short notice after talking about it this for many months. Ideally actually I think it should be done on site, to further expand the knowledge sharing. It would also be a bit of a perk for people inside a company that show leadership in a technology to have the opportunity to visit another company. Actually I want to also explore letting junior developers that have lets say 2-3 years of experience under their belt to temporarily switch their work place with another equally experienced developer at a different company for say 3-6 months. If your company would be interested in joining this please let me know.
Loose interface coupling
OK, I think this is likely a stupid crazy idea, but it has so much practical benefits at first sight that I want to bring it up on the blog and not just twitter. As a rule of thumb when writing code one should always try to reference an interface in type hints, instanceof or is_a() checks. This in theory allows people to replace the implementation if only for unit tests. But more importantly it could also allow someone to switch to an entirely different lib for the given dependency. One practical issue here is that either both projects need to share a common interface library or forced the need to write adapters in order for a 3rd party lib to become compatible even if the relevant API methods have the exact same names and signatures. Now lets imagine a world of collaboration where some subset of the community (as big as possible, as small as necessary) agrees on some common interfaces, but they don't want to burden their code with one dependency for each of these interfaces. Especially as for different libraries a different subset of the community could end up collaborating. Here I see 3 options: 1) each library bundles the interfaces (even though they sit in some common namespace), 2) each project asks their users to fetch the common interfaces from some other place 3) runtime "coupling". Option 3) doesn't exist today and is what this blog post is about.
Collaboration is scary
Collaboration usually requires communication and compromises. The pay off in the long run should come in the form of saved time, higher quality and a healthier ecosystem. But how does this all work out in practical terms? I remember a university course labeled "code is law". Talking about the hard facts that code defines. The topic there was mostly about stuff like how the default settings of apache define the reality of what gets logged and not whatever the governments privacy laws define. At the same time it can make collaboration harder, just because one group got their release out first (potentially rushed?) does it mean that their BC concerns outweigh your design concerns? Even if neither or both parties have released code to think about, you might have some other standards are tastes already developed that collide, how to decide the direction, especially if you have a sense you might end up being the junior partner? Now even if both sides are perfect gentle(wo)men will the end result not be some mushy half of everything compromise with no real world value?