"When it comes to monetizing and commercializing a F/OSS product, there is often the desire to offer differentiation through features or behavior in the software. This can lead to forking the software to various degrees or reinventing / replacing components or entire stacks.
There is no singular root cause for this, however, which makes it a really interesting issue. Sometimes the differentiation pressure comes from operating in an overly competitive space, sometimes from being in a market that has unique pressures or requirements and other times it comes from the desire to build brand identity. This leads to a situation where sometimes the differentiation is rather frivolous and other times more substantial and the result of a hard requirement."
If such differentiation efforts go wrong, it often will reflect poorly on your project even if it wasn't your fault. If differentiation is too hard, the downstream may look for another project to work with. If it all goes well, you may find a new source for upstream contributions. How we manage this phenomenon to get the best results? Here are some of my thoughts, and I'd love to hear yours as well in the comments section.
Be Aware
If at all possible, keeping some communication open with those who are working with your project is a great idea. This can often help make sure you are aware of what they might be wanting to change. Knowing there's something being shifted around is a great way to catch issues that may result before they happen, which is a great way to help your larger community avoid frivolous or just plain bad ideas. At the very least it can help you make sure that those differentiation efforts don't run into walls that the project team may have unintentionally erected that now stand in the way of these differentiation efforts. Or, if it's one of those twisted scenarios, it may give you the lead time needed to throw up such walls. ;)
Communicate Your Hopes and Dreams
Sometimes people want to differentiate your product in a way that works quite counter to what you have in mind. When this happens, communicate to those downstreams why you feel that way. Maybe they are trying to grab features or code that isn't ready yet (and thereby inflicting great pain on your shared users) in an attempt to beat others to the punch; maybe they are taking the software in a direction that conflicts with other things in the pipeline or which have been tried before and just don't work well; maybe there are opportunities to work together and make something even better. Regardless of the situation, a common cause for mistakes in the drive to differentiate is "we didn't understand the consequences and implications".
Of course, they may not heed your input, but I find that often they will try to and a compromise or even straight out agreement can be found.
Make The Software Flexible
There are going to be some areas in the software that people building products around it are going to want to customize. It could be as trivial as the artwork or template data but it could also be a lot more invasive.
Identifying the areas where such changes are likely to be made can then allow the team to make it easy to make such changes. When it's easy, mistakes will be fewer and the differentiation efforts will go smoother. This is perhaps the most powerful answer to the differentiation challenge because it helps channel efforts (if it's easy to differentiate on A and harder to differentiate on B, many will take the path of least resistance .. which is handy if you want them to stay away from B ;) and can substantially improve the results which in turn reflects positively on you and your project.
Identifying such areas of possible differentiation can happen in a number of ways: clever guesswork based on what you know about your software and the people who use it; talking with the people who are working on differentiation features; watching what different groups tend to add to or modify in your software.
Once identified, think about how to make it easy for people to add unique benefits or tweak what's there properly (whatever that means for your project). Sometimes a plugin interface can make all the difference (avoiding nasty invasive patches being applied to the code base), sometimes scripting interfaces that allow for easy changes at runtime can help, sometimes tools that help craft these changes with or even for the differentiator can be extremely useful. Ensuring that there are clear divisions between data and visualization and other tight-coupling-preventing measures can also help as they lower the cost and danger of changing one specific thing. Perhaps most important is documentation; it is always a winner as it will help people working with your project know what they can do and how best to do it.
When All Else Fails ..
When things turn nasty and a group really bungles up a differentiation attempt and your project is or will be getting painted in a poor light because of it, let that group know that you don't agree with what's going on and why (communication). Perhaps make a polite public service announcement for your users so they are aware of the situation. If need be, distance your project from that particular effort and try to do some damage control. Politely send people who come complaining to you about it politely to the people responsible for the bungle; eventually everyone will get the message.
Due to our projects being Free software, it is impossible to avoid attempts at differentiation being made by others. As much as possible, be accommodating of such efforts and encourage people to do cool things with your stuff. They may do things you don't agree with, but that's the beauty (or price, if you wish to look at it from a negative slant) of freedom. Accepting that can be a great remedy to what could otherwise be frustrating. This doesn't mean you need to be accommodating however; just because someone makes some change to your project that you don't agree with doesn't mean you are now required to offer support to their users for those changes or that your software should be forced to adopt those same changes.
Above all, though, watch what kind of differentiation works .. and then suck the best of those changes into your upstream project so that everyone can benefit.
No comments:
Post a Comment