search

ProgressNS / nativescript-ui-feedback

This repository is used for customer feedback regarding Telerik UI for NativeScript. The issues system here is used by customers who want to submit their feature requests or vote for existing ones.
Other
115 stars 21 forks source link

Why are these plugin not open source #1049

Open dottodot opened 5 years ago

dottodot commented 5 years ago

At the moment it's currently a lose lose situation for anyone who uses these plugins and comes an issue where the plugin doesn't work correctly.

We haven't paid for them so can't demand the issue to be fixed and we can't access the code to help with fixing the problems. This means if you're working to any kind of deadline you're pretty much screwed.

elena-p commented 5 years ago

Hi @dottodot,

The UI plugins are free but not open-source. However, contributions are now possible after signing a mutual NDA. If you or anyone else is interested to contribute, contact us at nativescriptplugins@progress.com.

dottodot commented 5 years ago

@elena-p I sent an email to that address and didn't get a reply.

elena-p commented 5 years ago

@dottodot, I apologise for the delayed email reply.

dottodot commented 5 years ago

I've submitted the NDA but not had any response.

lonerzzz commented 5 years ago

@elena-p You need something better than an NDA approach which is probably too onerous and likely unenforceable if signed by independent developers since you would have little recourse against them. Do you have plans to more widely communicate your approach? I see open items from 2016 in the list which will discourage people from using the platform. If you had active contributors, you would much more quickly reduce the number of outstanding items.

jspizziri commented 5 years ago

First, I want to echo what @lonerzzz stated.

Second, I want to point out the clear issue represented by @dottodot's comments and the fact that he hasn't been able to contribute yet. This indicates that the maintainers have so much on their plate they're not able to respond to community needs.

Finally, if NativeScript is going to thrive, it's critical to have a rich ecosystem of plugins that allow developers to build what they need to build. React Native's strategic advantage is the size and diversity of plugin ecosystem and community; which is something we need to replicate in NativeScript.

The Issue:

As other's have mentioned, the problem is that they're both free & closed-source. And it makes NativeScript much less desirable than React Native which has a far larger and more engaged ecosystem at the moment, which is entirely open source.

  1. These plugins are by far the most mature set of plugins that serve their need
  2. Because of their maturity and the fact that they're free & they discourage development of alternative OSS plugins that perform the same functions (a simple google search will yield a bunch of plugins that are no longer maintained because this UI suite is free now, making them unusable)
  3. Because they're not OSS they're not getting the attention they need to move the ecosystem forward
  4. No one has the ability to enhance the functionality to serve other niche needs.

A case study:

Problem: I have an existing app built in Angular and running it natively via Cordova. I want to move to a more native experience.

Solution: NativeScript is perfect! It lets me use my existing codebase and do a fairly moderate UI refactor without an entire logic rewrite and allows me to use the framework I love.

But there's a massive flaw...

Fundamental Flaw: After digging into a NativeScript conversion I find out that the UI Calendar can't actually be customized in the way I need it to be. I also can't contribute to the project or even fork it to fulfill project requirements.

Result: I'm left with basically one choice; switch to React Native. The benefit is that the ecosystem is far more robust and open source and there are calendars that will fulfill my requirements out of the box. The downside is that 1) I dislike React and 2) I want to use NativeScript.

I'd be willing to bet this type of situation is a really common occurrence for NativeScript hopefuls.

Question:

What's the competitive advantage of keeping these plugins free but also closed-source?

CC: @atanasovg @DimitarTodorov @dtopuzov @EddyVerbruggen @elena-p @etabakov @hshristov @jbristowe @jordanilchev @lini @NickIliev @PanayotCankov @r0bot @rdlauer @sis0k0 @vakrilov @ventsislav-georgiev @VladimirAmiorkov

etabakov commented 5 years ago

Hey @jspizziri, @dottodot, @lonerzzz,

Thanks for bringing up this question as it is an important one. First, I want to assure you that we understand your point of view and completely agree. Our team wouldn't be happier if those components were open sourced. The help from the community would be highly impactful and would help us to maintain the high quality of these components that we all expect.

Unfortunately, the NativeScript UI plugins share their codebase with other components which are being sold as part of the Telerik DevTools offering. As much as we would like to open source these components - we also need to protect the investments made in other commercial products which help us to continue to run NativeScript as a free and open source framework.

To try to overcome this situation, we tried to think out of the box and came up with this process of signing NDA. I understand that this is not perfect but still, it's at least a partial workaround. I also understand that this process might take more than we all would like, so we will try to make it more automated and with fewer touchpoints.

I hope that all of this makes sense to you. We will take your feedback and will try to come up with an improved process that addresses those shortcomings.

jspizziri commented 5 years ago

@etabakov, thank you for your response, it's greatly appreciated. I also understand the situation you're in.

Given that you agree that in an ideal world, these components could be open source; perhaps, we could have a conversation on this thread about potential strategies to work towards that goal (I'm making an assumption here that an open source strategy for these NativeScript plugins is not damaging to the aforementioned revenue model for Telerik). I'd be interested in your perspective on this. Here are some idea's I have:

  1. Open source any non-proprietary code you have for these plugins, along with documentation of the API provided by the proprietary code. Create some milestones a tickets to build an open source replacement for the aforementioned libraries and get the community involved.
  2. Adopt existing open source (and currently immature) plugins created by community members, put the NativeScript name on them, and encourage the community to adopt them and provide the expertise of the NativeScript core team to help get them up to snuff. Some examples:

For suggestion 2, I realize that trying to do all of these at the same time might be biting off more than could be chewed. However, I'd recommend setting up a roadmap and identifying a single plugin as the most valuable target and see how the community responds.

Thoughts?

jspizziri commented 5 years ago

@etabakov I just wanted to ping this issue.

lonerzzz commented 4 years ago

@etabakov Another ping on this issue since your team has not responded.