Hello, everyone: I am writing this email to propose a project I did work on earlier. The project introduces support of feature flags for the OSGi environment. Probably many of you already know about feature flags or feature toggles. I would like to further elaborate a bit for those who are not familiar with it.
It turns out that when many people hear the term feature flags, they fixate on the word - flag and are thinking of something much older - other flags in software engineering. They are referring to a compile-time flag or a server configuration flag or maybe a server configuration file. While those are indeed flags, what they all have in common is that they are global. What I mean by that is they impact every user passing through that piece of software. But when I say feature flags, sometimes called feature toggles or ops-toggles, I’m talking about a very different thing. I’m referring to making a dynamic decision in my code - live. I’m deciding which way I’m going to send a user, without having to push new code and without having to change a config file. It’s not static, like those other examples of flags. It’s a user-by-user, session-by-session decision. The key benefit of using feature flags is that they decouple development from app releases. This means two things: * features can be merged before they are fully implemented * fully implemented features can remain hidden until you are ready to release them First and foremost, feature flags help developers because incomplete features can be merged! This allows to split a feature into many small increments and merge those branches one by one. Secondly, feature flags also help with releasing. In the old days, an app release could get blocked when finding a last-minute issue on a new feature. Thanks to feature flags, this can no longer happen! If a feature isn’t fully ready, it can just be temporarily disabled. Even more, when a feature is ready to ship, you no longer have to do a big bang roll out to all users. Instead, you can gradually roll out and make a data-driven decision on to roll out further or maybe even rollback! That dramatically de-risks rolling out new features. Finally, improvements to new features can be built side by the side of the old feature and using A/B tests you can then decide which feature should remain. This allows optimising user engagement in your app. I believe this was sufficient to portray the idea behind feature flags. I have worked on a prototype version [1] of the feature flags that leverages pure OSGi specifications. Being an Eclipse committer, I see several benefits of making such a project flourish under the supervision of the developers working on Felix. As Felix community primarily focuses on OSGi, this project would avail benefits from further development, maintenance and adoption. Currently, the project is licensed under the Apache 2.0 software license, but it still uses my top-level domain in the bundles. If you think the project would be valuable, I would love to make the bundle names compatible with the Felix naming conventions. I would really appreciate your opinion regarding this proposal for the contribution. Thanks and Regards, Amit [1] - https://github.com/amitjoy/feature-flags-for-osgi
