Real open source — the user mindset
This is explaining why a true open source license means much more than “I can have it for free and see the source code”. This particular post is the inverse perspective to an earlier writeup of mine. They say the same things, they are just differently easy to absorb for different kinds of readers.
So what does the user think when he/she demands that a “real” open source license is required for them to use a given piece of software?
“When I start using a software I am making an investment. The money for buying the software (if any) is an irrelevant detail. The real investment is in personal energy, in time, in relationship building with others who use or provide that software. I am in the position to pick, and others are influenced by my pick. Whether it is friends following my choices or employees that I make use that software, there is more investment.
The software must not be taken away from me later.
That I have a commercial license to use the current version until the end of time is not actually useful. I must have updates. No software can be used without updates.
The problem here is that the vendor might develop the software in a direction that I don’t want to or call not follow. If there is no true open source license on it then that can happen at any time, and I lose my investment. Software has a long lifecycle, especially software used to build other software or procedures on top. There is no way to decide to trust a vendor for that long based on a 2-month history.
If there is a true open source license on the software then I know that I have the right to take any given version and develop independently from there. And I can share my new development of that existing code with other users that might also not like the new direction that the original vendor took. That protects my investment. That is called “splitting” an open source project.
Not only is my investment protected by being able to “break loose” — having this right can also be used to influence the vendor into not developing the software where the users do not want it to go. That doesn’t do much if I’m the only one having a problem with the new direction. But if I have a point with my concerns, and several other customers make the same point, and a potential split would involve multiple customers, then there is leverage on the vendor. If they do something that would make the software useless for many users, those users (including me) are not helpless.”
If the vendor just lets the user see the source code, but does not grant the right to re-publish user-changed versions of that source code, none of this works. The vendor expects the user to voluntarily become a lock-in victim, source code readable or not. Whether that is acceptable to the user or not is highly dependent on the commercial setting and on the nature of the software. Generally, the more that software is used to build other things on top of it (other software, as in vendor provides development tools), the less likely it is that a lock-in is accepted. That is why programming language implementations were the first major open source wave.
On the other hand, nothing prevents the flow of money for support, training and customization to go from the users to the original vendor regardless of what license was used. If it is true open source, then the vendor needs to be able to compete against others that could offer the same support. That shouldn’t be a problem is the vendor is a professional software company and has good retention of the people who made the software in the first place. Those employees’ expertise makes their employer’s support much better.
You might be able to guess where I am going with that last statement. Another reason why customer might require a true open source license on the software is that it applies pressure on the vendor to stay the most competent and agile expert organization on that software. This weeds out companies who behaved like jerks, lost all their original developers and now try to milk the existing customers based on a lock-in license although there really is no actual expertise in-house anymore.
Obviously the latter situation also easily develops if the software or the company making it is sold. Users are reluctant to invest (not money, the other things) in software that can change ownership.
