Autodesk letter and archicad opportunities

[Ahmed_K]

Hi mates, you all here have seen the letter writen by architects to Autodesk, and so more are joining it,
This could be a great opportunity to GRAPHISOFT to catch bew users, and make the community bigger
More focus on agressive marketing,

[jl_lt]

Brett wrote:

This is yet another example where Graphisoft puts profits first, large AEC firms second (years of features only for them), and last, 1-5 seat practices who mostly have to pay the larger costs (having to fork out for Teamwork) for their years of unanswered wishes.

So in essence, Graphisoft is no better than Autodesk, contrary to what many keep harping on here.

May i ask why would any big software business, like Autodesk or Nemetschek, not put profit first, for they, as any small business must also survive? The diference lies in how, why and for what they make that profit.

[Nader Belal]

Sorry to make this interruption every one, but this has just gotten published by Anthony Frausto-Robledo, editor-in-chief at Architosh.com

https://mailchi.mp/cf8ac9ab4b94/welcome-to-insider-xpresso-12555690

The parts that I liked:

When a tool has become so well established around core strengths that are years of development ahead of the competition, what the AECO market is asking for—by looking at the market's behaviors, as in the case of SketchUp use inside Scott Brownrigg—is the integration of those tools. This point is repeatedly missed by established software players and the giants in the industry in particular. Sometimes we see a stunning reversal of what is the "normative error," as in when Graphisoft, well known for coding nearly everything themselves, chose to integrate McNeel's popular Rhino + Grasshopper into Archicad. Instead of embracing such a route, Autodesk built Dynamo. And Vectorworks built Marionette.

And for those who know me on this forum, I always tried to push the idea that Graphisoft should at least increase its appeal to Rhino + Grasshopper community as the BIM platform to go for those users that have their workflow centered around Rhino + Grasshopper, as that their core design philosophies share many similar traits.

The open letter ends with several asks, including a "ground up" replacement for Revit. There is much irony in this request. If the letter's participants mostly see more value in integrations than in a full-stack solution from a single vendor, if indeed they envision a future of "expanded geometry support and alignment with international data standards"—all code words for make Revit work better with Rhino + Grasshopper and help us move data between other non-Autodesk tools—then aren't they in a sense asking to embrace a new vision of how the whole process can work? And if so, why are they asking for Autodesk to be at the very center of that new vision when other companies have been pushing for that agenda for much longer?

That statement is the most eloquent version of what have been stated in this thread, if those firms aren't moving away from #Revit then what we are seeing is just a fee negotiation.

And perhaps its best answer does, in fact, lie in Ana Matic's statement that the relationship firms have with Autodesk is like a marriage. But who will be the mediator? Iain Godwin told me just a day ago that behind the scenes, these firms have never been so open in discussions about considering alternatives. And the reality is there is no counseling in the AECO market. There are just market providers and consumers and competitors.

[schagemann]

Sorry if I sound like a broken record, as I have stated this in multiple places before, but IMHO most of these problems basically stem from marketing driven feature bloat.

So we find ourselves caught in an annual release cycle, resulting in buggy first versions with new features that we hardly ever use and if at all only until after a few updates, when it is finally stable enough for production.

Unfortunately, this hubris applies to pretty much all software manufactures and packages (and one could argue to most established companies).

However, in the spirit of positive thinking and given the massive investments we all have in them, let's encourage the AutoDesks and Nemetscheks (Adobe, Trimble, etc.) of this world to do the following:

1. move funding from marketing departments back into software development;

2. replace all Managers without AEC background and replace them with seasoned industry experts from within the AEC community;

3. concentrate on core features and improve them year over year, i.e. do not absorb or waste resources to develop features that others are already better at - instead support these 3rd parties with the best possible (native file format) integration;

4. for any new major features consult your existing user base first - then check against 3...

i know this sounds ambitious, but hey one can dream...

At least I for one (and I suspect most of our clients) would happily pay for an ever improving core set of features that enhance our daily workflows & efficiency.

And also to counter the argument that shiny new features sell products to new users, I say let those that fall for it go, once reality kicks in they will eventually come to their senses.

Btw. another Manufacturer to mention in this ever increasing price spiral is Trimble with SKUP. After a massive price hike for NETWORK licenses earlier this year, they have recently announced that from November 2020 on there will be only subscription based licenses available, essentially eliminating network licenses!

[jl_lt]

schagemann wrote:

1. move funding from marketing departments back into software development;

2. replace all Managers without AEC background and replace them with seasoned industry experts from within the AEC community;

3. concentrate on core features and improve them year over year, i.e. do not absorb or waste resources to develop features that others are already better at - instead support these 3rd parties with the best possible (native file format) integration;

4. for any new major features consult your existing user base first - then check against 3...

i know this sounds ambitious, but hey one can dream...

Points number 1 and 2 are probably almost completely out of our control (but we can keep asking... or someone here could get him or herself hired by Graphisoft and work from the inside!).

3 and 4 are very doable... man, if only someone proposed an idea to clasify and analize the data we already have to detect the most sought after features and focus our energies on them to get the maximum result with the least amount of resourses!

[Bricklyne Clarence]

schagemann wrote:
......

However, in the spirit of positive thinking and given the massive investments we all have in them, let's encourage the AutoDesks and Nemetscheks (Adobe, Trimble, etc.) of this world to do the following:

1. move funding from marketing departments back into software development;

2. replace all Managers without AEC background and replace them with seasoned industry experts from within the AEC community;

3. concentrate on core features and improve them year over year, i.e. do not absorb or waste resources to develop features that others are already better at - instead support these 3rd parties with the best possible (native file format) integration;

4. for any new major features consult your existing user base first - then check against 3...

i know this sounds ambitious, but hey one can dream...
.....

Those are all great ideas.

Unfortunately for them to be workable, they assume to exist a 2-way (healthy) dialog between developers and the end-users.
That currently hardly exists in any substantive form with this software.

As someone upthread pointed out, we're now down to a situation where they (Graphisoft) give you users what they think the users need as opposed to what the users themselves want (or more importantly ask for).
That's not a recipe for and enjoyable experience using their software or in the long-term for a workable one at all, IMHO.

It's worth mentioning that as far as Sketchup, Sketchup users and Trimble are concerned, a lot of Sketchup users feel that ever since Trimble bought out the software from Google, it's hit something of a development or innovation rut, in terms of new and visionary tools and productivity features, and that most of what's pushing the software forward these days is third-party developers creating productivity plugins and tools rather than Trimble themselves.
At least they have a very healthy stable of third-party plugin developers (thanks mostly to the Ruby interface and Sketchup's developer-friendly SDK and Ruby API).
Unfortunately that kind of situation also tends to lend itself to the type of scenario where the developer feels they don't need to address a lot of the core issues with the software if,......'...there's a plugin for that!'

[schagemann]

Yes it is a dream - however, contemplating it some more it is actually just common sense.

Nothing more, nothing less.

You raise an interesting point though regarding the healthy 3rd party extension universe for both SketchUP and Rhino. In fact I am not sure I agree that this is necessarily a good approach, since as far as I understand that this was what Graphisoft originally encouraged, and over the years resulted in 'bolted' on ARCHICAD features - from memory the original Stair & Mesh Tools started out as 3rd party Add-ons that then got absorbed. Other such efforts were the MaxonForm and Zermatt 'integrations'...

And going back to basics, even back in the early days, was it really a good idea to create an architectural software without a proper Stair or Window Tool in the first place?

Which brings me to the bigger picture, I do appreciate that software development and resource management across big teams are driven by complex decision making processes, however I also think the perceived complexity of doing the right thing for most users often results in the wrong decisions being made. Burning Resources on any team based endeavour for flexibilities sake, inevitably results in overly complex and totally unnecessary outcomes.

The best example that comes to mind, are the various IFC property management interfaces over the last few years. I am yet to find anyone who actually thinks that this is working well... please get in touch if you actually benefit from this process to be that flexible and ultimately complex?

IMHO a simple way out of this complexity, is to focus your Resources primarily on the basic feature set, continuously improve and innovate on it and then, with whatever is left, experiment with any additional new features via the afore mentioned experienced user feedback loop.

In fact you can see similar patterns of dysfunctional processes throughout history, typically companies get into trouble once the non engineers start to dominate the decision making process. Think of the Sculley Apple era (just found out he came from PepsiCo...!) and the latest unfortunate example is Boeing...

Whichever way it goes, someone needs to take back the controls and make some clear decisions.

[Nader Belal]

@schagemann

Nice comment

Anyway there is another methodology for software creation that solves those issues that you have just raised here, that was already implemented by Mc Neel with Rhino as David Rutten have mentioned in 3.1 Programming in Rhino and I quote

McNeel has taken a rather exotic approach which elimates several big problems. The technical term for this approach is “eating your own dogfood” and it essentially boils down to McNeel programmers using the same tools as 3rd party programmers. Rather than adding code to Rhino itself, McNeel programmers prefer writing a plugin instead. For one, if they screw up the collateral damage is usually fairly minor. It also means that the SDK (Software Development Kit, that which is used to build plugins) is rigorously tested internally and there is no need to maintain and support a separate product. Unfortunately the result of this policy has made plugins so powerful that it is very easy for ill-informed programmers to crash Rhino. This is slightly less true for those developers that use the dotNET SDK to write plugins and it doesn’t apply at all to us, scripters. A common proverb in the software industry states that you can easily shoot yourself in the foot with programming, but you can take your whole leg off with C++. Scripters rarely have to deal with anymore more severe than a paper-cut.

To put it simply, let the wanna be programmers script their plugins & etc, and let the public use it, test it, & criticise it, when it is improved, bring it closer to the core, and one day, you can just flip it or incorporate it to the program's main core.

[Bricklyne Clarence]

schagemann wrote:
Yes it is a dream - however, contemplating it some more it is actually just common sense.

Nothing more, nothing less.

You raise an interesting point though regarding the healthy 3rd party extension universe for both SketchUP and Rhino. In fact I am not sure I agree that this is necessarily a good approach, since as far as I understand that this was what Graphisoft originally encouraged, and over the years resulted in 'bolted' on ARCHICAD features - from memory the original Stair & Mesh Tools started out as 3rd party Add-ons that then got absorbed. Other such efforts were the MaxonForm and Zermatt 'integrations'...

And going back to basics, even back in the early days, was it really a good idea to create an architectural software without a proper Stair or Window Tool in the first place?

Which brings me to the bigger picture, I do appreciate that software development and resource management across big teams are driven by complex decision making processes, however I also think the perceived complexity of doing the right thing for most users often results in the wrong decisions being made. Burning Resources on any team based endeavour for flexibilities sake, inevitably results in overly complex and totally unnecessary outcomes.

The best example that comes to mind, are the various IFC property management interfaces over the last few years. I am yet to find anyone who actually thinks that this is working well... please get in touch if you actually benefit from this process to be that flexible and ultimately complex?

IMHO a simple way out of this complexity, is to focus your Resources primarily on the basic feature set, continuously improve and innovate on it and then, with whatever is left, experiment with any additional new features via the afore mentioned experienced user feedback loop.

I mean, if they tried hard at it, they could find a nice middle ground between the two approaches ( Having and helping foster a healthy plugin/3rd party extension Ecosystem, while also robustly developing the core software itself and improving its feature set such that users never have to resort to the plugins).
There's nothing wrong with having a strong stair tool as a core program tool and feature while at the same time having the option of a 3rd party tool that approaches the function differently and does things that the core tool can't (and vice versa).
For example, I still frequently use the 3DMD rail tool (because it's so quick and intuitive and has a lot of template options), while at the same time (less frequently, admittedly) also using ArchiCAD's own rail tool when the ocassion calls for it.
It doesn't have to be a one-or-the-other, 'mutually exclusive' type-deal

And to wit (and also to add on to what Moonlight wrote), there's the added dimension that when this is done properly it actually helps the core software and Graphisoft developers themselves in the long run.

Just as an (obvious) example, Grasshopper started out as a 3rd party plugin to Rhino3D and university grad school project by David Rutten, and because it became so popular, so robust and so emblematic of McNeel's forward thinking development of Rhino - and also thanks to McNeel's own heavy support of Rutten's work, it was eventually absorbed completely into the core program and is now a core feature (even while it runs and operates as if it's a plugin) for the most recent versions.
In fact, its development was so successful and well-sourced (froma robust community encouraged by McNeel) that even Grasshopper itself has its own ecosystem and universe of plugins to extend its own functions and connect it (and Rhino) to other programs (....like ArchiCAD).
That kind of development environment that encourages that sort of back-and-forth open collaboration and bleeding between user community and program's developers as well as interested (serious) outside developers simply would never exist with Graphisoft and ArchiCAD given their hand-off approach to the user community let alone anyone who might be interested in developing an extension for the program.

Along with some of the key differences that Moonlight highlighted with McNeel's approach (which I should add, is in the same vein of a similar attitude they have in the development of Rhino itself - particularly with regards to their open and extended beta-testing of new versions, and their constant sourcing of help and feedback from their own user community) it would necessitate Graphisoft to be somethings that they've sadly demonstrated they're just not capable of being to that extent. Mainly, pro-active in this approach, deliberative and collaborative and truly open to feedback.

You mentioned 'back in the old days'. I'm a long-term enough user to remember back at a time when GS developers used to openly interact with users in these same forums. I see they're starting to make appearances again here and there - but in a more tepid and measured way - so perhaps there's hope for the future. But that would just be the first in a long line of steps they would need to take.

(*.....geeez, I remember Maxonform,...but I'd totally forgotten about Zermatt. To be fair to GS though, there were some 3rd party extensions and tools and objects I remember that were developed and were pretty good, but sadly fell off the vine. Anyone remember the Ceiling Tool? A wonderful library object for quickly modeling out ceiling structures with lighting and mechanical features. And that one DID have Graphisoft support (I belive it was being developed by one of their former developers) and one that I would have loved to see developed further and possibly absorbed into the program down the road.)

schagemann wrote:
In fact you can see similar patterns of dysfunctional processes throughout history, typically companies get into trouble once the non engineers start to dominate the decision making process. Think of the Sculley Apple era (just found out he came from PepsiCo...!) and the latest unfortunate example is Boeing...

Whichever way it goes, someone needs to take back the controls and make some clear decisions.

So. Much. All of THIS!

[Nader Belal]

@Bricklyne Clarence

Thank you, and in line of what you were saying read this thread from this point and so on
https://archicad-talk.graphisoft.com/viewtopic.php?p=295001#p295001

[jl_lt]

So far i had been proposing that the roadmap, though desirable, would not be that useful. But it was because i was just assuming a bidirectional, albeit dim, dialogue between graphisoft and its users, where users should press even more.

Even though i mentioned it elsewhere, for the sake of the current discussion at no point did i consider the posibility of third party developers and coding enthusiasts who can and should develop add ons and scripts (an environment that i admitedly know nothing about). In that sense, after reading these last posts, and assuming the involvent of this third party actually occurs, then the roadmap would be an efficient way to direct the efforts. therefor I stand corrected on this one. Still, wanting them post it is not enough, so the same question remains: what can be done for GS to post it?