[
https://issues.apache.org/jira/browse/APEXCORE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15704240#comment-15704240
]
Chinmay Kolhatkar edited comment on APEXCORE-576 at 11/29/16 5:22 AM:
----------------------------------------------------------------------
Here is the thought process behind why I proposed this idea.
I think we do have a good level of contributions to Apex and Malhar as of now.
But IMO this is growing or going to grow in future. In which case, for
accepting the code into apex or malhar with right level of maturity might be
tough. At the same time, external contributors including individuals or
enterprise may or may not find enough time to contribute to mainstream
following all the processes but might have a valuable code which would enhance
Apex.
Having a registry like mechanism where one could register their code (in their
own repositry) to be working with Apache Apex gives a low barrier to entry at
the same time providing larger feature set and contribution to Apache Apex
overall. We'll need to have a process defined for what is "low barrier" to get
into this registry and what is "standard barrier" to get into mainstream.
With this registry we could have an indexing of such extensions for easy search
and usage, making life easier for users of apex too.
Spark packages were released at the beginning of 2015, and there are already
290+ packages there, which is a good number in 2 years IMO. Their processes
might not suit us at all, but the idea is worth investigating I think.
I believe this is a win-win situation for Apex community, apex user and apex
contributors. With our growing community and usage, we would quickly need a way
to manage the right quality and large contributions and I think this can solve
that problem.
was (Author: chinmay):
Hi All,
Here is the thought process behind why I proposed this idea.
I think we do have a good level of contributions to Apex and Malhar as of now.
But IMO this is growing or going to grow in future. In which case, for
accepting the code into apex or malhar with right level of maturity might be
tough. At the same time, external contributors including individuals or
enterprise may or may not find enough time to contribute to mainstream
following all the processes and they might have a valuable code which would
enhance Apex.
Having a registry like mechanism where one could register their code to be
working with Apache Apex gives a low barrier to entry at the same time
providing larger feature set and contribution to Apache Apex overall. We'll
need to have a process defined for what is "low barrier" to get into this
registry and what is "standard barrier" to get into mainstream.
With this registry we could have an indexing of such extensions for each search
and usage making life easier for users of apex too.
Spark packages were released at the beginning of 2015, and there are already
290+ packages there which is a good number in 2 years IMO.
We need not follow the process they have at all, but the idea is worth
investigating I think.
I believe this is a win-win situation for Apex community, apex user and apex
contributors. With our growing community and usage, we would quickly need a way
to manage the quality and contribution and I think this can solve that problem.
-Chinmay.
> Apex/Malhar Extensions
> ----------------------
>
> Key: APEXCORE-576
> URL: https://issues.apache.org/jira/browse/APEXCORE-576
> Project: Apache Apex Core
> Issue Type: New Feature
> Components: Website
> Reporter: Chinmay Kolhatkar
>
> The purpose of this task is to provide a way to external contributors to make
> better contributions to Apache Apex project.
> The idea looks something like this:
> 1. One could have extension to apex core/malhar in their own repository and
> just register itself with Apache Apex.
> 2. As it matures and find more and more use we can consume that in mainstream
> releases.
> 3. Some possibilities of of Apex extensions are as follows:
> a. Operators - DataSources, DataDestinations, Parsers, Formatters,
> Processing etc.
> b. Apex Engine Plugables
> c. External Integrations
> d. Integration with other platform like Machine learning, Graph engines
> etc.
> e. Application which are ready to use.
> d. Apex related tools which can ease the development and usage of apex.
> The initial discussion about this has happened here:
> https://lists.apache.org/thread.html/3d6ca2b46c53df77f37f54d64e18607a623c5a54f439e1afebfbef35@%3Cdev.apex.apache.org%3E
> More concrete discussion/implementation proposal required for this task to
> progress.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
