Concerns and discussion about Bubble and the Plugin universe

Questions
1

Having posted this initially in a discussion over on the following thread:

These are some of the questions, after reading through the thread, and discussing with fellow Bubblers, here are some concerns that need to be addressed about the Plugin universe.

  • Does Bubble have a policy for when a plugin provider moves on or decides not support to update a plugin any more? (For example, do we then have access to the plugin code)

  • Is there an expected SLA to be part of the plugin supplier network? What is that SLA? What if that SLA is not met? As a customer, how much can we rely on an SLA enforcement?

  • What is the purpose of the third party plugin network: Alleviate Bubbles need to build new features? Give Bubblers the opportunity to extend their apps? Or transition towards traditional development in the Bubble universe? How much will we need to consider traditional development for our apps in the future?

  • How do non developers who came here to build without code feel about the growing reliance on third party plugins for new features?

Having already invested about 6 months of my time in learning and created an app, the whole reliance on plugins for extended features is concerning for many of the above reasons! If I now need to start learning JavaScript for the future I would rather know now than be left with a looming disaster when I have customers paying me money.

4 Likes
2

Definitely interested in getting access to the code if a developer leaves so another developer can pick up where they left off

1 Like
3

Valid concerns.

However, realism is essential to being successful. It is bit unrealistic to expect high levels of complexity or personalized functionality from “no-code”. Bubble as a company would likely not survive long term if they attempted to build a platform that vanilla could address every edge case functionality.

I do understand your point, though, about wanting some assurances about how well a plug-in that requires JS is supported long term. On the other hand, if Bubble were to provide tight guidelines at this stage about how all plugins must themselves be no code - without major market share in this space - they wouldn’t be able to attract enough plugin developers. As it is, some of the most useful plugins in the library aren’t really no code.

And even if Bubble did, they’d kind of be a nightmare to build plugins for. A good parallel is developing apps for iOS. If they didn’t have so much market share, I’d venture a guess that a majority of iOS developers would avoid the platform altogether. Apple is an absolute nightmare to develop on from an administrative standpoint when compared to Google’s more laid back approach to enforcing standards of how an app should operate.

At this stage, I’d still rather break out the JavaScript than have a strictly no code platform where the platform owner tells me how my app has to be built.

4

@projectvisionhealth

Valid points, but for those of us who aren’t coders it kind of goes against the reason we came here in the first place. If you can code in JavaScript then your position would be more secure than those of us who don’t have that skill base.

However, the point being if we are to rely on the development community, like any other software engagement I would expect a basic SLA for my business and if there isn’t one then it needs to be clear so that we can make an informed decision before committing to third party developer plugins. “I will repsond to your issues when I can” is just not good enough!

I would even say that if you are looking to “break out the code” then what’s the point using a “No code platform”?

On Bubbles home page front and centre it says clearly"

Build software by pointing and clicking
You don’t need to be a coder

Maybe it should say:

Build software by pointing and clicking
Mostly you don’t need to be a coder

Rhetorical question, but making a point :slight_smile:

3 Likes
5

Thanks for raising this @StevenM I look forward to their response. My biggest worry is the support level and reliability of independent developers / plugins.

From a non-coder consumer in this market, I just want to drag and drop without having to learn JavaScript and the ins-and-outs of api calls/requests, etc… if my capabilities are restricted it, then so be it. Many streamline website builders are doing very well in their market, even with their limitations.

1 Like
6

Again, to be realistic, the true market value of a no-code (or code-lite) platform is to dramatically reduce the cost of building an MVP.

Either your app will grow big enough and generate enough money/investment that you’ll hire your own dev team and own your future code base. Or it will gradually die and you’ll eventually abandon the project. I don’t see there being a middle ground, where a company indefinitely uses Bubble even as they build out their own internal dev resources. And I don’t see Bubble being a place for outsourcing your dev team. You can’t scale that.

And I think the Bubble team realizes this, and are trying to figure out what the “sticky” point is for repeat paying customers and building a scalable business. Is Bubble the place you come to make your MVPs? Or the place where people are willing to sink money into “hobby” apps? Or a new best-practices app back-end platform? I don’t think they have the money/resources to be all three. #2 doesn’t represent a scalable business (or really even one worth chasing, given the potential of their tech).

2 Likes
7

Ah, but @projectvisionhealth there you have a traditional developers hat on! I am here to build the App and scale and Bubble have made it clear they are here to help us do that.

I think a lot of people on here would disagree with you.

If Bubble are not able to take us past MVP, a lot of us a wasting our time!

Regardless of that, even on MVP you need a SLA for plugin support.

2 Likes
8

No, I disagree. Many businesses have built their company websites using website builders and have continued with doing so for many years.

Not everyone has come here to make their millions from developing apps. Bubble can be a vital tool for many businesses who wish to develop their own web based apps to manage the daily and general running of their business.

Bubble can be the future and next generation of website-type-builders. Why just have a website when customers can login, pay invoices, make orders, etc, etc… all on a bespoke system built and run by the company!? But sadly, the more complex Bubble make it, the more off-putting it will be for businesses to invest their time and money in it. Just look at GoDaddy, they seem to be doing alright!

2 Likes
9

I’m looking at this from the perspective of a venture backed company, which is the direction Bubble has to go if they want to continue to adequately support their growing customer base. In order to raise the kind of money they need to fully support an SLA (and they clearly don’t have enough on staff to do that now), they will need to promise their investors exponential growth. Their business decisions will reflect that. And I know for certain that investors would pressure them to go after revenue from bigger businesses, meaning proportionally more services targeted at business looking to scale and less at business happy to remain at 5 employees indefinitely.

@mikescullion GoDaddy isn’t the best example because the majority of their revenue comes from domain registration and basic web/email hosting. Squarespace and Wix eat their lunch when it comes to website building.

In my opinion, focusing on “websites plus” as you suggest wouldn’t be a good move, as Squarespace and Wordpesss are already there and has way more money to execute and grab market share. And that would be a massive underutilization of the core capabilities of the Bubble platform anyway. Bubble is for making apps, not merely high powered websites - and there is a clear difference between those two things.

1 Like
10

Great points and agree the platform needs tighter SLA, but many Bubblers have already benefited from some of the features and improvements adopted to support thier bigger customers.

That’s probably a discussion to have with Bubble if your business gets to that stage.

We are getting a little off topic though - the original post was to discuss issues around third party plugin support.

Please see some of the questions posted above.

11

You can’t talk 3rd party plugin support without first understanding Bubble’s broader business direction. They’re also a team of what, 5 full time people? This discussion will yield more actionable insights for them once they’ve actually raised some capital. Right now, their cut of plugins money helps subsidize server uptime and availability.

12

Hey guys, these are all great questions. Here’s how we’re thinking about things right now. As context, we’re actively working on our plugin marketplace policies and terms right now, and plan to publish a much more substantial set of terms when we leave beta and open up building paid plugins to the public. That said, I can preview the direction we’re going with this.

I’ll start with the purpose of the plugin network. This is actually something we were thinking about from day 1… we’re finally getting around to actually implementing it, but this is something we’ve always wanted to do.

We see “no code” as being like building with legos: starting with small pieces, you can snap things together and create things in ways that the lego designers never imagined.

Our job with Bubble is to do a couple things: a) make it really easy to snap legos together in all kinds of different configurations, and b) make sure there are legos in as many different colors, shapes, and sizes as possible (plus the cool robotic ones with motors, and lights, etc.)

For a, we see that as long-term being done by the Bubble team – that’s the core of our product, and while we think what we have today is pretty good, there’s a lot of dimensions on which we’d like to make it better.

For b, we view our role as managing the overall health, but we don’t think the best way to have as much variety as possible is to build all the different lego pieces ourselves. We’ve done it to start with, to get things off the ground, but our vision is to have millions of different lego pieces, for every conceivable possible need, and we think opening things up to the community is a much better way to get there than trying to hire and manage a million developers ourselves.

To switch analogies, we think a forest is healthier and robust than a managed garden. We could decide exactly which plugins are going to be built, how they are going to be used, and what they are going to be priced at, but we think that giving our users freedom to see what works for themselves (tempered by moderation and oversight by the Bubble team) is a much better way of building a healthy ecosystem.

So I don’t see a conflict at all between plugin-building and no-code: no code is about having as many pieces as possible, and as flexible a system as possible for combining them. It’s just a question of who builds the pieces. We want the community to contribute to building the pieces so that we can spend our energy making sure the tools for snapping them together are as powerful as needed. To @projectvisionhealth’s point, we’re still a small team, and we’re actively working on making sure Bubble is a platform that people can trust their businesses with: that’s definitely a full time job right now and there’s a lot we can improve on.

I think one of the big concern behind @StevenM’s questions is, okay, you guys are already trusting us with your apps, but now we’re asking you to trust a bunch of 3rd parties, too. What happens if they flake out, or don’t do a good job supporting the things they built?

One important thing in the marketplace terms we are drafting is that if a plugin seller stops selling a particular plugin, that plugin does not get automatically removed from user apps. Rather, it becomes free, so that people can continue using it until they can find a replacement (or, if it just works, keep using it forever). We aren’t planning to make the code public if that happens without the seller’s consent, but plugin users won’t have to worry about their apps suddenly not working.

We have a couple tools in mind to help ensure the quality of the ecosystem, and I’m sure we’ll evolve more over time as we see what happens. The main tools:

  • Moderation by the Bubble team. If plugins are getting a lot of complaints from users, and the developers aren’t being good citizens and helping resolve them, we’ll remove plugins, or, if necessary, developers, from the platform

  • Reviews and feedback. I know right now reviews are a little thin on the ground, but as the plugin system grows this will be more important, and we’ll be adding more tools to help float relevant reviews to the top of the list.

  • Aligning financial incentives. I discussed the subscription system on the original thread, but I think it’s important to point out how valuable aligned incentives is for this kind of thing.

  • Availability of alternatives. We plan to actively recruit developers to participate in the platform, and if there’s a gap, we’ll point people that way. We want the Bubble plugin store to eventually look like the Apple app store where there’s always multiple good alternatives for every need

6 Likes
13

Thanks @josh this helps answer many of the questions.

Reviews is a good start, but it would also be helpful if on the developers plugin page there was an option for them to state support times for the plugin and perhaps average response times.

Self moderation is good in the long term but when you have customers screaming at you you need to have some general idea around support times.

We can then at least make an informed choice about who we buy from.

What do other Bubblers think??

14

The “bubble plugin universe” is pretty much just an online marketplace, which has a fairly templated business model, right? So we can look to the success of Apple’s App store (or similar) for context and as a framework for answering these questions. In that light, I think some of these questions and concerns start to contradict each other.

It’s natural to expect a significant price gap between a product and its peripherals. iPhones and their paid apps, for example, differ in price per unit by around 98% on average, (educated guess, excluding service fees). Bubble’s, on the other hand, is closer to 0% or less. Which product’s percentage is better? That depends. Would you rather pay $600 for an iPhone or $15? Would you rather pay $600 for Bubble or $15? Bubble’s price gap is uniquely beneficially low. If anything, plugin prices could be used to argue that Bubble itself should be more expensive than any plugin, (and when you upgrade your plan it can be).

Features vs. Plugins: Bubble as a company really isn’t in the business of building applications, but of equipping others to build. The only application Bubble ever builds and sells is its own. If you look at the features provided through plugins, they aren’t really “Bubble” features… They don’t modify Bubble’s code to enhance our user experience. Instead, plugins allow us to add to our app’s code to enhance the ux of our own end-users. This is better because it allows Bubble to focus their limited resources on back-end improvements; things like performance upgrades, bug fixes, data manipulation, UX, processing improvements, etc. - things that 3rd parties don’t even have access to. There’s no way Bubble could fulfill every single request in a timely manner, nor could they adequately support and iterate on every single one of them. Regulated plugins fill this gap for the better.

In terms of others coming along and building similar (or better… or worse) versions of existing plugins and selling at a reduced price; that’s really more of an ideological concern. It’s also a contradictory one, because you want to maintain both exceptionally and universally low market prices and exceptionally and universally high product quality. In order for these to coexist sustainably, there needs to be competition. Competition not only lowers prices but is a breeding ground for progression. I think the problem you’re wanting to solve here has much easier solutions; regulation and user experience design. Bubble is already regulating submissions. Most markets (e.g. Apple, Google,) solve it via default sorting, filtering, and aggregating its product list. Most commonly, these options prioritize products based on attributes like popularity, feedback (quality rating), price, release date, and category. The biggest problem with Bubble’s current marketplace as a whole is that its design fails to clearly prioritize the list with quality by default, and fails to effectively promote user feedback that would provide those numbers.

Sure, a plugin author can stop supporting the plugin, neglect it, or simply forego improving it, but that’s far more likely to happen to free plugins than paid ones. The higher the price of a plugin, more than likely the more motivated its author will be to support it. Additionally, authors develop positive or negative reputations this way. Still, negligence can (and does) happen, but payment is a stronger motivator than being forced (which really can’t be "en"forced in this scenario anyway). Like you expressed, even if a plugin does get neglected, anyone who recognizes the plugin’s demand is free to take it as an opportunity to provide an alternative and reap the benefits.

All things considered, and especially with the upcoming improvements, we’re in pretty good shape.

4 Likes