Increasing Forge Quality

Hello everyone,

I’m writing this post to let you know that we are starting a long and exciting journey to improve the quality of components in our Forge.

Why are we doing this?

We know that quality assurance of components is an issue we’ve been intermittently working on for the past years, however it has not been enough and your feedback is proof of that.

We clearly have a path of improvement in front of us.

Where we’ll start

The topic of quality in software development will always be a hot topic, it is dependent on an array of variables: why the software is being built, where and when it will be used and so on.

Components with old versions, usually are not maintained or have low engagement. This is cluttering Forge, hiding the good quality ones and sending a message of unreliability to our users.

We need a decluttered vision of Forge, learn from the process, iterate and build on top to avoid this happening again.

Why this criteria?

Only versions 10 and 11 are now supported by OutSystems and the majority of our customers are already running on those versions.

We know that the platform version is not the sole indicator of quality but components on older versions are prone to have deprecated development patterns or dependencies to outdated platform libraries.

The plan

Starting tomorrow, any components that have not been downloaded in the past year and do not support at least version 10 will be deactivated.

On July 15th, we will be deactivating any components that have not been updated to support at least version 10.. We’ll do this gradually, starting by the oldest versions and we always reach out to component owners to deactivate or update them until the deadline.

If you are the author of one of the components, don’t worry - they won’t go away! You can still find them in the forge under the “My Components” filter.  They just disappear from the search for everyone else.

After July 15th, we’ll do a retrospective on this first phase and proceed to tackle other issues. One thing that stands out are copies of the same component.  A quick example would be to search for “S3” as in Amazon S3. There are 4 results. Trying to understand the difference between them, why they all exist, etc is something we are trying to look at and solve for.  

In parallel we are analysing friction points and prioritizing them with your feedback so we can improve our current Forge experience.

We will also update the current guidance we have on how to build a Forge component and what is expected from community members.

This might feel like a deja-vu and a slow, unuseful step but the only thing we need to be successful is to take that first step.

Thank you for being part of the OutSystems Community!

Good move

Aleluia!

Much needed . (y) 

Really good initiative :) 

Nice.. 

Thanks for this sharing!

Good decision

Indeed much needed.

This will be very appreciated. Thanks

Very good! Such an operation is really necessary.

Thanks!

Good to clean up old components that will no longer be used or are not being downloaded

Good move although I'm do wonder why having multiple packages that pursue the same goal is an issue. It can be a different implementation, it can be a different use-case. I think that diversity is a good thing, there is no one-size-fits-all for a lot of things. Some components are not accepting developers so perhaps that is a reason for someone to publish a new component, and this is a good thing! Please handle this topic with care. 

I also wonder what more is on the roadmap for the Forge, perhaps you can also give some insight into this?

• Are we for instance going to allow "pull requests" so that people that are not associated with an component can upload a new version with some changes and allow the owner(s) of the component to review these and merge it with their component.
• Are "Try Me" demo components going to be hosted on an environment that is managed by OutSystems that will never shut down? Nothing annoys me more then an component of mine is not available via the "Try Me" option because I went on an holiday or was working on another project for several weeks and my environment shutdown because of this.
• and a lot more

Thank you for the feedback!

Yes, we don't want to kill diversity and trying to turn components into huge libraries will not be beneficial for the users installing them. 

What we are aiming for is to understand why we have so many Google Maps, S3 components, for example. If in the end we find out that all of them make sense then we must understand how findability can be improved so a user that just wants a maps integration is not overloaded with 10 options.

Regarding the bullet points, we do have those options and more written down to be analysed. This initiative started less than a month ago, the only thing I'm capable of sharing is what's in the initial post.

We are sharing early so we can get the Community's view on this topic early on in the process which I believe will enable us to do a better job :)

Let's clean the house! Nice move.

Yes this subject is a major issue and a long-lasting concern. Glad it finally starts to get the attention it needs.

Clean up is a nice move, but quality of the components is more necessary I think

I think we really need a team to take a look and approve the component before it is published out for others to download

Great news.

Regarding duplicates, please also check this idea: 

https://www.outsystems.com/ideas/5488/forge-should-block-component-if-it-has-duplicate-ss-key-in-modules

Shingo Lam wrote:

This is already being worked on by OutSystems in collaboration with OutSystems MVPs and component teams.

Shingo Lam wrote:

Hi, I agree with Shingo. I think that should be mandatory to have sample/demo pages

Vincent Koning wrote:

Hi Vincent, first of all, thank you for your feedback. As Cristiana said we are in parallel analyzing friction points and collecting feedback of possible improvements to later prioritize. So I'm very interested in hearing more from you, regarding the "a lot more" things you'd like to see on the Forge, can you send me more details?
Thank you.

Luís Cardoso wrote:

The problem can be that it's not always possible to have working demo's. Let's take an integration component with Microsoft Sharepoint Online for instance. To be able to integrate with this service you will need valid logon accounts and configured the underlying security. Same goes with mapping components. When accessing certain map providers (like Google or Bing) you will need an API key. This key costs money so I as a developer will not provide a working demo page since I don't want the possible costs associated with it. Therefor I don't think that a demo page should be mandatory as it's not practical or even possible to have working demo pages for every component.

Those are very good news!

Nice! Good to know and happy to help!!!

Focusing on the quality of the forge components must be the first and foremost focal point. It's your store and you should take responsibility for it, like any fair marketplace. It provides trust to the whole ecosystem by making the high quality and engaging app available (on the top). Various other marketplace has a well-defined set of principles, guidelines and practices which one must adhere before submitting the solution to the store. For instance, large marketplaces like Apple has App Store review guidelines, Google has an extensive launch checklist. Didn't OutSystems also put the critieria for programs like MVP to publish new forge components each quarter? I know, this is not the only criteria, but one of them to keep continuing their membership?.

The guidelines published here have some flaws and doesn't cater to edge cases, 

1. "Components with old versions, are cluttering Forge, hiding the good quality ones": OutSystems should have by default only the supported versions (currently v10, v11) checked in the filter of forge-search. If the legacy users want to search for an older version, they should uncheck all and check only the version they are looking for. There are a few clients still stuck with v9 and will slowly phase out the application if not supported well. A large array of customers had built massive applications on v10 and no plan to migrate anytime soon. 
2. "Only versions 10 and 11 are now supported by OutSystems": In 6 months period of time, v10 will be an unsupported platform. Will OutSystems take down all those forge components which were built for v10 and not explicitly marked for v11 by the component team(s). We have seen few of them are forward compatible (not by design) and well running on v11. I've seen a compatibility meter on some marketplace, where the users downloading X version of the plugin/component can mark if the plugin was compatible with the Y version of the platform. This helps next user to make a quick decision.
3. "components that have not been downloaded in the past year...will be deactivated": There is an easy escape, the component team may download it once in a while every year?!
4. "deactivating the components, but letting them appear in My Components": How does this help?
5. "copies of the same component": This is a welcome step, and should have already been handled. The idea of blocking the component with duplicate SS Key in modules is in radar for nearly two years, but no progress?! Thanks, Tim for bringing Justin's idea in the discussion.
6. Instead of taking down the components, I would advocate the idea (I mentioned it a couple of times and glad that Vincent has the same opinion) of opening it to the broader community using forks to improve and push new versions as pull requests or merge requests. Award the contributing member with points or badge once her/his PR/MR are accepted.
7. As mentioned by Vincent, about "Try Now", it must be on the OutSystems managed environment which doesn't sleep. I keep receiving the message for the same reason. While working on N number of different environments, you not necessarily visit your personal-environment every now and then which results as environment going down and had to Wake up explicitly.
8.  Bringing the "Try Now" demo on the OutSystems managed environment, will also make it available for all the component team member to nudge and publish it, as and when required. 
9. Such initiatives which have a major impact on the community should come as multiple ideas to vote up/down, to be able to collaboratively draft the guiding principle and policy. 
10. I've explicitly not mentioned the name of any component.

Regards,

Swatantra

As stated in the master post, we have two motions in place right now: Component curation and Forge improvements. 

We are starting with a small step when it comes to component curation but is one that we feel it's needed to strengthen the relationship between Community Members and Forge. At the same time we are bringing the right people together to ensure we improve Forge's capabilities.

While I think Apple and Google's App Store distribute apps that are a bit different from what we can find on Forge right now, I understand your reasoning. Even Apple had to do this in order to make it the industry reference for how to distribute apps built by the community. We'll get there :)

Regarding the points you brought up:

1 & 2 - Components should support the latest version of the platform to take advantage of new libraries, APIs or newer and better development patterns that are made possible by that version. This also applies to components that work fine on several versions: it might work fine but a harmless reference to an outdated library (jQuery for instance) can be the source of those bugs that take hours to solve. 

We will work to have a Forge with clearer guidelines and the right tools that enable users have their components up to date.

3 - This behavior is taken into account, we are also working on better ways to understand real usage of the component.

4 - It helps if the owner wants to reactivate or submit a new version of the component.

5 - The issue with duplicate SSKeys is a bit complex to solve, but we are aware of this. This is no excuse for not having an update in two years.
6 - Opening components for community collaboration is the main path we are looking at to improve quality.

7 & 8 & 9 - Thanks for bringing that up. There are a lot of ideas describing your points, I'd suggest everyone reading this to upvote those ideas and bring new ones.

So to make this clear, this is the first step. It is not the only step.

We are starting this initiative right now and it will be a long journey. We will build this in collaboration with the community. This first announcement aimed to be transparent with the community and to start conversations like these. Thank you for that!

Would it be interesting to have a sort of 'estimated quality score' for Forge components, based on the history of versions, downloads, reviews, and credentials of the component's team?

Or would it be worth to try to monitor the number of deployments of the component to OutSystems Cloud Production environments, for instance?

Hello again to everyone following this topic.

First of all, we appreciate all the feedback that is being shared here and in other channels! Keep it coming, it's important for us to know your opinion.

We already reached out to owners of components that do not use a supported version of the platform, sharing this initiative and its deadline as well as opening another channel for feedback.

We are two weeks away from the deadline, so if you own a component or are part of a team take some time to check if the component should be upgraded and maintained or the use case it is trying to solve is no longer a issue and should be deactivated.

Thank you for your collaboration and effort,

Let's do this team! :)

100%