Next, download the project which appears to have the most overlap with your intended product. Scope the code, audit it for quality, comments, structure and evenness. If it passes muster, you read through the documentation to determine if there's a section to jumpstart new developers into the complexities of the code base. Most of the good open source software projects have this, which is what enables them to become good open source projects.
Now, start making some mods, for example stylesheet changes, logo changes, form changes etc. You want to get a feel for how much time and effort would be involved to get up to speed with this code, and how much effort would be involved in adding any missing functionality your putative product may need, which this open source project lacks.
It's now up to you to determine if indeed utilising this codebase will get you to your intended destination faster than if you started from scratch. Bear in mind a few things however; many widely-used open source projects have seen successive iterations of quality and security feedback, loopsÃ, Code being fixed and enhanced and security exploits being patched. If you start your project from scratch, it may be years before you reach a similar maturity level. Factor this cost in to your decision process too.
Do the right thing by the existing project community; make contact, alerting them to the fact that you intend to build a commercial application upon their codebase, but that you will comply with the licence they have stipulated for the project. Contact with the open source developer community isn't mandatory, just common courtesy.
By commercial support, I mean commercial support. Charge the customers $200 per hour for it, but make sure you deliver the goods. You should also play the perpetual code escrow card. Many potential customers of vertical business applications need to be guaranteed that they will not be left stranded when deploying a new line of business system.
This is one of the main reasons encountered when Australian firms have trouble competing against larger international players. The argument goes that buyers are unsure of smaller Australian firms' business longevity and worry about code escrow. Ensuring that potential customers have full access to the source code is a great way of nullifying this competitive disadvantage.
In short, open sourcing saves you many of the marketing and sales costs necessary in taking your application globally. If your product is good, and there is a global market for it, you have a far greater chance of reaching that market through open sourcing.
Achieving the same marketing reach using traditional means, would cost millionsââ,¬"money that few Australian developers have. News of good quality open source projects travels fast.
Next up, provide installation, customisation and enhancement services. This is where the real money is. Show the market you are a serious commercial open source player. Whilst your code is indeed open source, and your users could extend it themselves, most businesses do not have the time nor the inclination to undertake this kind of activity; it's not their core business. Firms will instead turn to you.
Additionally, no one should know the code as well as you, and your time to build for extensions and any integration work will far exceed others' value delivery. All you need to do is capture just a small percentage of all those users who pulled down a free download and you can generate some real revenue with customisation work. And because any such resultant work can be open source too, you can slowly build upon the functionality of your product, thus attracting more users.
Finally, you can make money by re-licencing. Just because you licence your software under an open source licence, doesn't mean you can't also licence it under non-open source terms as well. For various tactical reasons, the best open source licence to use for this purpose is the General Public Licence (GPL). This approach works especially well for libraries and for products which you could classify as 'engines', such as computing engines (scientific and engineering), database or transactional engines. By using the GPL, anyone who links to your engine or library and plans to redistribute that combination as a total product must also licence their own IP under the GPL.
Many potential customers would prefer not to do this, which gives you the opportunity to sell them a version of your product which is not based on an open source licence. Are there issues with open source licences when reusing the code of others? Specifically, aren't we in trouble if we reuse open source code in our own projects? In most circumstances, no. Most developers in Australia are building bespoke software, which is not for redistribution beyond the client purchasing the service.
This model is compatible with all open source licences. If you or your client wants to redistribute modified binaries of GPL licenced products, you must also supply the source code to your modifications under the GPL.
If you use any of the BSD-like licences (Apache, MIT etc.) only attribution is needed within your derived modified binaries. You do not need to make available the source code to your modifications.
For the full text visit www.builderau.com
No comments:
Post a Comment