I just finished watching the video (by @JustinTSE) in @georgemelkadze’s opening post in the linked topic above) - and I’m coming around to agreeing with him (and many others) that it would be a good idea for SketchUp to - I’m going to say “adopt” – third party extensions - and make them part of SketchUp Pro - as extension packages that are bundled with SketchUp Pro, maintained by SketchUp (which could include contracting with the original developers), and updated through the Extension Manager window (which I ALSO wish was more like the Sketchucation store’s update process - but that’s NOT what I want to talk about here!).
Yes. I know that some extension developers make their livings, or significant portions thereof, from their extensions, and that that can be problematical in the context of SketchUp “adopting” them into Sketchup. Again - that’s not what I discussed in this topic! If you want to address that - please start your own topic!
So what do I want discussed here?
ASSUMING SketchUp decides to offer more extension packages that extend the features of SketchUp Pro (as they’ve already done with Sandbox Tools and Dynamic Components - which are extension packages that are optional - in that they can be disabled):
What would YOU suggest be the packages that SketchUp “adopt”? And what existing extensions would you include in each package?
If your package contains paid extensions, please make note of that, but don’t refrain from including them - assume that, should SketchUp want to include them, they’ll make a deal that’s acceptable to the developer to allow the developer to keep deriving income - and would likely include a modicum of control as well. Again, general outlines and/or specifics of any potential agreement structures between the developers and SketchUp should be it’s own topic - if you want to talk about it!
I suppose I kind of set this firestorm off - so I should weigh in.
I was kind of thinking about different extensions kind of being broken up by disclipline, so for example things like “Simple Modeling,” “Advanced Modeling,” “Architecture,” “Woodworking,” etc.
Within those, you could see some of the features people have been requesting. Simple modeling, for example, could have tools like mirror, line trim features, etc. Advanced modeling could have tools similar to the transform tools in Rhino, like Twist, Bend, etc. I think Sandbox tools could be upgraded with a 3D Gizmo, subdivision tools, etc.
These could be toggled on and off depending on the needs of the user. Kind of a brainstorm on my part, but it would allow the interface to be kept simple but expanded as needed, plus they could be more uniform in operation, instead of people having to learn a bunch of different UI’s for different extensions.
I do think there’s a discussion about some of the third party developers that have created extensions and not just copying their work (I don’t think SketchUp should roll out their own Profile Builder clone, for example), but some tools, like mirroring and trim are pretty standard across 3D packages, and in my opinion, just because they’ve been added by 3rd parties doesn’t mean SketchUp should just…not include them officially.
Interesting discussion - I’m interested to see where it goes
Extensions are in a weird place right now in Sketchup. There is the good old Sketchucation side, there is the new Extension Warehouse side, there are some old places like smustard - it’s a bit of a mess of where and how to get them. Also on how to pay them - try adding extensions in a company environment for multiple users. Nightmare!
Then there are the three Sketchup-Versions: Pro, Web, iPad and only one version that can actually support extensions. And yet - it’s what made and makes Sketchup great.
I couldn’t work without extensions and that’s why iPad & Web will stay toys for me until they support them. However - as somebody pointed out to me recently: Web & iPad Sketchup are completely different beasts. Extensions would need to be majorly revamped in order to actually work.
Which brings us to the “official extensions packages” idea of @JustinTSE . Introducing new extensions along with iPad & web support would maybe be a possibility to not being accused of “just copying FredoScale”.
Copying extension functionality would be a terrible move from Trimble all together. Remember the outcry when SketchPlus was released? Add a bit of Trimble to that and you have a nice little community PR scandle.
So - where do we go from here? Only the good folks at Trimble know - and hopefully have a plan for.
Another possibility I could imagine however would be this: If the billing of the Extensions would be part of your “Trimble-bill” (a bit like in the Apple App Store) you could safely curate all these extensions, and also offer “bundles” like “FredoScale + Eneroth Component Replacer + OpenCutList” (I know OCL is free - but it’s good for carpenters) a user could say: "hey - that’s great - I am a carpenter - that’s what I need - you might get a discount for purchasing a bundle and next time you install Sketchup 2024 or whatever - all your bundles are there for downloading again.
I like @JustinTSE idea of bundling extensions into design verticals — which I think would work even better if SU incorporated a Work Space capability into their UI. (which would help in supporting complex workflows while reducing interface clutter).
There are several interconnected issues invoked by SU’s extensible architecture — and I have thoughts on most of them! — but to keep this discussion focused, I’ll address just the benefits of official SU extension bundles :
Workflow Enablement: For each workflow vertical, if SU identifies and incorporates a combination of the leading independent extensions with in-house solutions, then unifies and tunes the resulting package to the needs of specific industry workflows, the benefits would be huge. It would also help marketing and product development to have directly-identified audiences for different aspects of their offerings for product feedback, development input and sales targeting.
UI Consistency: The primary benefit of this bundles would be the unification of UI conventions and widgets across currently disparate tools. One of the biggest issues in working with multiple extensions is the variation in UI. For example, I love the functionality and scope of Fredo6’s extensions, but there is no relation between his UI conventions and those of SU proper. This makes for constant context switching and adds an unnecessary additional cognitive load to each action.
Official Support: As recent instances of unreliable developer support show (CabMaker / Skalp / Curic) one of the weaknesses of the SU Extension model is the reliance on support from (often solo) independent developers. This is especially unacceptable for professional design firms whose project workflow runs through an under-supported extension. And what happens when a developer either simply loses interest or capacity and unilaterally drops support from a (paid) extension?
Simplified Discoverability: It is difficult and time-consuming for users to wade through the thicket of overlapping extensions to identify the one(s) that meet their needs. Official SU bundles that do this work for them — delivered in a pre-curated package — would save time/frustration and improve user satisfaction.
ETA - Unified License Management: Extension license management can be a nightmare across all the different platforms (EWH / Sketchucation, Gumroad etc. — along with solo developer-managed). For workflow-critical extensions, having them licensed together and folded into existing Trimble subscription accounts would simplify and consolidate management and related support issues — especially for multi-seat licenses.
As for whether these should be paid or free, my thought is that the more generalized ones (such as Advanced Modelling) could be incorporated into the base app for free. The industry vertical bundles (such as Architecture) could be packaged as a broader design solution with expanded asset, scrapbook and material libraries and sold as upgrades to the available subscription options.
See I don’t agree with this assessment - I love our third party developers, but at the same time, just because a third party developer included a common tool that’s included in other 3D modeling programs doesn’t mean now SketchUp is barred from including that in a base toolset, even if it is an extension.
SketchPlus or Curic, or anyone else, for example don’t hold license over the idea of a mirror tool.
I also don’t think SketchUp should just copy the more complex extensions that have been created by third party developers.
I think that SketchUp needs to be clear on what they’re trying to achieve (pick a direction) and figure out what tools are necessary to do that, but they can’t just not add tools because they’re already in extensions.
Personally I’m not imagining these as additional paid packages to add new modeling features, but more as a vehicle for SketchUp to add features that the program needs to stay competitive while maintaining simplicity.
The whole point of the subscription model (at least as it’s been described) is to provide recurring revenue to pay the costs associated with the development and upkeep of SketchUp. ALSO charging for those upgrades in the form of making new extension features paid seems like it would leave a very bad taste in people’s mouths.
I suppose it is a model they could try, but I can guarantee the reception would not be warm
Leading on from the discussion about “vertical” extension sets makes me wonder whether Trimble (or this forum) think they know what user groups they have. An obvious one is architecture, together with sub-species of that such as landscaping. Another big group would be crafts, such as modelmakers and carpentry. After that, I struggle. You do see people wanting to do all sorts of weird things that I might think unsuitable for SU but often they succeed (usually with @mihai.s 's help!). Maybe gaming environments is another big one.
My point is that you can’t even begin thinking about extension groups until you know your user groups and what they are likely to want. So it’s a good place to start if Trimble want to go down this route.
I should imagine introduction of something along the lines of Sketchup Pro Plus, where on top of a regular Sketchup Pro install one would get appropriate boxes to tick which should include the requested extensions in your download with corresponding price included in your payment plan.
Developers would then submit their offerings to sketchup to be curated accordingly and would thus benefit from direct and regulated income and the user would have everything available in one place, updated or not as the case may be with each Sketchup version upgrade.
Surprisingly enough, I run into this same issue when planning content for my YouTube channel. Woodworking content, for example, only appeals to woodworkers, not to the rest of my audience. It actually makes dialing in a content strategy difficult - I’d imagine it makes creating a comprehensive software update strategy difficult internally at SketchUp as well.
Sigh … it seems many ignored my request to talk ONLY about which “bundles” they propose should exist, and which extensions they should contain - and we’ve veered into OTHER issues raised by the very idea of “Official” Extension Packages.
So Be It.
Here’s what I envision:
SketchUp would put together the packages - in conjunction with the original developers. SketchUp would NOT be writing the extensions themselves. (Exception below)
For extensions currently offered for free, I would expect that SketchUp would negotiate a one time payment to the developer for the rights - and perhaps also a maintenance contract where the developer would continue to support the extension and provide any updates necessary as new versions of SketchUp come out.
For extensions currently offered with a license fee, the above holds true PLUS some recurring payment to the developer in lieu of the license fees they won’t be receiving on a per-extension basis.
Once the contents of the various packages are settled, SketchUp would evaluate THEIR costs for each extension, aggregate them, throw in a bit of profit, and offer them as OPTIONAL packages, available for whatever cost they decide, through the Extension Warehouse. It would be SketchUp’s choice as to whether to offer them as subscriptions, or as a one time fee.
The exception to SketchUp not coding the extensions would be any they determine are needed - but have been orphaned by the original developer - assuming they can’t get the original developer to do the work - or if they can’t FIND the original developer after sufficient due diligence. I don’t think there would be many in this category.
And I only have 1 “package” that I envision - based on most of MY modeling - and the extensions I use:
Package Name: Building Structures - would include Medeek’s Wall, Truss, Foundation, (perhaps) Electrical, plus anything else @Medeek comes up with that could reasonably be included in the package!
For paid extension, a bundle could offer a savings, and Medeek BIM as an example does that now. I’m not sure I see any benefit to a bundle of free plugins other than maybe managing updates like Fredo’s (now paid) or Sketchucation’s manager app, which I like.
I think the real question is what things that are currently relied on as plugins should be rolled into the base program. I understand wanting the plugin community to thrive and not crush it by stealing delopers ideas and putting them out of business, but now that there are web and iPad versions that can’t have plugins, you have to wonder about actually pulling some plugins into the program. That could lead to different versions of the “base” program, I suppose, if you want to have different options and price points.
STL file creation was originally a plugin, but when they make SU for Schools, they rolled it into the program so it would work on the web version. @JustinTSE mentions Weld as another example.
I am really sorry, I understand what you are after, but Justin’s video has kicked off a conversation about fundamental issues that should be addressed before we get to extension packages. Perhaps we need a different thread called, “Basic Modeling Plugins You Would Not Want to Have to Live Without” because some of us are not so interested in the more comprehensive extensions but would instead like to see more native capability included in the base program.
The benefit to bundles of basic plugins whether free or paid is dependability. The ‘managing updates’ you mention is not a trivial matter for people who rely on SU for business. I agree with your ‘real question,’ and it will be a thorny issue. But there are very basic 3D modelling functions that are just missing from SU.
This is a good moment to define ‘plugin.’ To me, a ‘plugin’ is an extension of basic modeling ability that SU lacks–like the Fredo6 suite. I am not talking about Medeek’s excellent products which are what I would call ‘comprehensive apps based on the SU 3D engine.’ Any Trimble support or incorporation of such an app into a ‘package’ should be a contractual arrangement between Trimble and the developer. I am also not talking about ‘specialty extensions like cabinet layout extensions or cut lists, although they could certainly be included in some future millwork package. I am talking about general usage modelling plugins—here’s an example that is not a Fredo plugin: Upright Extruder.
As it stands, a new SU Pro is released each year and it is left to us to rummage through our plugins/extensions, decide what we want to keep and reinstall them ourselves. Trimble is nowhere in this picture. Have plugin problems? Talk to the forum people, they’ll sort you out.
I would like to see Trimble shoulder some responsibility for providing basic modelling capability that SU natively lacks. We should face reality—developers will not always be around to update their plugins. People running day-to-day businesses don’t want to wake up one morning and not be able to use TopoShaper or CurviLoft or RoundCorner because the developer has retired to Tahiti.
Actually, that’s specifically what he requested in this thread -
The other post was more about the overall issues and discussion. He specifically requested discussion about here about possible extension packages, not about native capabilities in the program - it seems fair to honor his request here and continue the rest of the discussion in the other thread…
