BDN developers, MicroStation users need your applications to work with CONNECT Edition applications. Why?
It’s time to update because MicroStation users are updating to the CONNECT Edition and want your applications for their workflows. Additionally, support for your older version application will be discontinued concurrently with the product’s support. It’s time to embrace new technologies that enable better capabilities and faster performance so we continue to deliver the best experience for users
BDN members, get started now. Download the latest MicroStation CONNECT Edition SDK in the Fulfillment Center .
Learn more about Bentley’s Developer Network, or contact us to become a BDM member.
[Mark] More (better?) communication will be welcome. As I wrote earlier, it was important topic on our list. It's not simple task to balance frequency (too frequent disrupting communication is as bad as no communication) and "richness" (I prefer to have limited number of sources), but we have good examples from the past (like quaterly BDN news existed few years ago) that worked well.
[Mark] ... or even open to other BDN members. It was not. Let's say it was better next step in my communication based on my former posts and complains and it's was much more efficient ;-)
[Mark] I have received newsletters from BDN I have not received anything for a few years. The last BDNnews I found in my archive is from 2013. I liked this quaterly updates, because I know it's not many developers priority (or even possibility) to regularly check different forums, downloads and wiki pages to evaluate what is new.
[Mark] I think many of us would like to contribute more. I am not quite sure. It's not requirement, nothing mandatory. I am aware many people are too busy or not interested in any communication, but I also from time to time talk with people that complain a lot about development (bugs in SDK, not enough documentation etc.), but they do not post any single question to forum. This is for me the worst case.
[Mark] And, many of us, especially those of us who have been working with InRoads or Geopak, are just now having to move code projects to OpenRoads. Yes, and it's painful process sometimes. I asked (and I also posted to Ideas) to create separate communities for civil and building development (the same as we have for geospatial and ProjectWise), because APIs and the product itself are different from MicroStation.
[Mark] Maybe I need a reminder of how to find out. Lack of training materials (that complement API doc) was discussed also. Some change were implemented already, e.g. see Videos link at Developers and Programming main page (that seems to work as a signpost now). Not too much, but good start. And I like YouTube in the same way as I dislike old-style, slow and confusing Bentley LEARN server.
[Mark] We're more likely to communicate via forums like this when we have met each other. It builds trust. Despite of I am quite strong introvert, I agree with you for 100%! :-) Nothing can replace personal contact.
[Mark] Github.com - I don't think example code needs to be limited to those delivered with the SDK(s). We discussed it also (and not only Github.com, but also Github pages and other popular tools). In any enterprise corporate (it's not specific to Bentley) an acceptance of these new technologies is slow process, not only because of more complex environment, but there are also legal issues etc. But there is some development already at Bentley side and also nobody protect anybody to create own repository with own examples.
But when talking about examples, in my opinion (and I presented it during the call also) we don't need better API documentation or more code snippets (ok, it would help a bit of course ;-), but tutorials, guidelines and explanations of general concepts, rules and recommended practices. My example is when I will teach you everything about all car parts (how combustion works and pistons are designed, about injection molding etc.), you still be not able to build a car or to be a good driver, because they are different type of knowledge. Details about classes and methods can be always discussed in the forum(s), but it's hard to reach this step when you don't know how to use the classes and how to structure your project.
And there are many new concepts in CONNECT Edition like ribbon customization with completely new type of commands, very complex and powerfull MstnTool classes etc. Plus there is huge lack of information about EC world (EC Framework, schemas, API, how it works etc.) ... I have been playing with EC for last 5 years, so my knowledge is over above average I guess, but still is not good enough. And without knowing EC, you are able to utilize only small part of CONNECT Edition features and power and it will be worse when iModelHub and i-model 2 will be in published.
Oops, another lenghty comment :-)))
Thank you very much for your contributions. I definitely appreciate your efforts.
Here are a few thoughts, and these are for the Bentley BDN team as well as for everyone else who might follow this thread.
More (better?) communication will be welcome. I was unaware this meeting was happening or even open to other BDN members. I definitely would have liked to participate. I have received newsletters from BDN, but I would like to see these more frequently.
Community contributions - I think many of us would like to contribute more. And I believe we will. I'm beginning to see names of people I work with and it's been a while since I've seen them post questions (and solutions). A lot of the posts in the past two to three years have focused on CONNECT tech. And, many of us, especially those of us who have been working with InRoads or Geopak, are just now having to move code projects to OpenRoads. Until this year we have been working with almost 20 year old tech. And, it wasn't that long ago that I was migrating V7 code to V8i.
Dev conference and training opportunities - anything planned? Maybe I need a reminder of how to find out. Opportunities like these encourage engagement and participation in community forums. We're more likely to communicate via forums like this when we have met each other. It builds trust. I think Bentley BDN needs to offer (again) annual dev conferences or similar.
Github.com - I don't think example code needs to be limited to those delivered with the SDK(s). I propose we start posting sample code on github.com. I'd like to see Bentley do the same. When they answer a customer questions (and assuming it's not proprietary) let's put the examples where we can get it, create new branches and extend the ideas.
I thought about to write a notice, but I was busy and you were faster with your question ;-)
The call was open and valuable and it took more than we scheduled originally, but we went through many topics and issues. I appreciate Robert Hook, Sujeet and Sunand spent time at this call. Bob recorded notes, so I am sure nothing will be lost. But I assume it's understandable that it has to be evaluated what can be changed (because it's in BDN / dev teams responsibility) and prioritized and balanced between resources needed and expected output.
Some notes and thoughts, not all discussed during the call, but some just arised as a result of discussed issues:
So what came out of this call? Im sure many of us are interesed to hear the status of this.
Thank you for taking the opportunity to be on a call with us tomorrow so we can openly discuss and approach being on the same page of issues you have brought up/mentioned, status updates for existing issues in our backlog priorities, what we are/may be considering in the near (or distant) future, and best practice resources and processes that have the highest success to affect change, etc.
Hi Mary Kay,
when I read your blog with your “call for development” for the first time, my thought whether it’s a kind of joke, a weird sociological test or an author is living somewhere in an ivory tower and know nothing about real situation.
It would be nice to know more about you, because it would help to understand from what position, with what priorities and aims the blog was written. It’s strange that you as Bentley employee has zero personal information at the community web, but fortunately some are available at your LinkedIn profile. Such situation does not bring any confidence to the blog content.
I do not know what worldwide situation is when talking about migrating applications to CONNECT Edition platform, but I’d like to provide local personal perspective how Bentley are actively working to be an evil, not partner, and to lost both development forces and market share when talking about 3rd party developers. I am aware my local experience (Czech Republic, where I live, plus several other EU countries I am in contact because of projects or communication with users and friends) cannot be generalized, but from talks and some posts at BE Communities it’s seems the problems are not local.Why to migrate an application? It looks like “the chicken and the egg” situation, because why to invest a lot of money to migrate the code when there are no users, but there are no users because there are no applications?
In my opinion the problem is somewhere else: What I have seen for last few years is process when users have stopped to use MicroStation and other Bentley products as their main tool and have converted to competitive alternatives. There are more reasons like slow development (and even slower repair of reported bugs), delayed release of power products like ABD, ORD or BM, bad translation, no support for local and EU standards (critical for building and civil), ignoring open data sources and initiatives (and without access to data, it’s very expensive or even not possible to use any product today) etc. No solution and no solution provider are perfect, but many from the mentioned problems can be solved (or to implement temporary workaround at least) using 3rd party applications, both from independent developers or in-house. What Bentley have done to increase number of developers, to make the development simpler and how they support dev community?
Comparing to the most of competitors (Autodesk, ESRI…) and community driven solution (Postgre / PostGIS, Geoserver…), they actively fight not with, but against developers to demotivate them, to block access and to make the whole process bureaucratic.
Several different types or levels of application development can be recognized and formed to a pyramid: students, hobby and in-house developers and professional developers. When students gain experience with a product and its SDK, they can help with in-house development and to solve specific requirements and to fill gaps that always exist when “big worldwide solution” is used. The same applies to hobby, free-time and in-house developers, often recruited from normal users interested in software development. Some small tools and macros can become so popular they can grow to commercial solution. Also, some part-time developers grow to be professional developers. So, there are two chains: people with potentially growing software development skills and applications growing from simple and specific macros to widely used complex apps. These chains and internal dependencies must be managed and developed as the whole lifecycle.
What (the most of) competitors offer: Clear and well-structured information available at web pages, single click SDKs and other materials downloads (registration required in some cased), developers documentation including tutorials(!) and dev blogs(!) available freely. Let’s imagine a student working on his project or project / CAD admin trying to make the project more efficient. It’s very simple to read available materials, based on obtained information to download a proper tool and to do some hand-on testing quickly.
What Bentley does? Zero information about development at web pages, no public access to development documentation, no dev blog and restricted (BDN membership required) access to SDKs.
What does it mean for students and users: When there are more products used, they will be choose not Bentley, because there are no information and very small community and access to SDK requires to sign and agreement: slow and not acceptable in many companies. In fact, to contact Bentley, negotiation with managers etc. probably requires the same amount of time to have first working beta of a code implemented on competitive platform.What does it mean for managers: Very limited (practically zero) number of available tools (compare with plenty of both free and commercial macros and tools available for other platforms) and very limited knowledge of development coming with students and new employees (because they have no chance to test and play with MicroStation and other APIs). It makes using Bentley products more expensive and less flexible, especially when solving local specifics, local regulations and data formats.
What does it mean for independent developers: The development is far more expensive comparing to other platforms, because it’s not possible to hire a person with MicroStation API knowledge and because there are no tutorials, best practices and very limited examples and community, such person has to be trained internally … for a normal developer, to train him MicroStation, best practices, API and general concepts, it may require even a year to swap from learning to producing working code. No chance for such investment in today highly competitive and quick sprint-based world.And what will happen when a user or company decided to become BDN member? Literally, nothing. The program is completely dysfunctional. Whereas on other platforms it’s clearly defined what is a bonus to become member of developers’ program (e.g. access to extra API, extra documentation, guaranteed support etc.), the only real advantage of BDN is an availability to download SDK. Nothing else.
There is nothing like “program”, because there is zero communication, zero members support, it’s not clear what is BDN team and who is responsible for what, what are long term aims etc. Even BDN conferences organized long time ago (including recordings!) were abandoned as well as workshops, training materials and materials like BDNzine in the past. Comparing to other program memberships I have personal experience with, for Bentley the independent developers are difficult insects not worth to establish professional communication and to build long term win-win relationship. When I normally receive emails about strategy of products development, news, blogs about planned and implemented changes, welcome notes when new manager is hired, planned events from different companies and communities, why do you expect I will choose Bentley with zero interest in cooperation with external developers?
There is the only exception: People like Bob, Arnold, Paul, Yongan and others provides valuable response to problems discussed in programming forums. I guess they are often the last reason why some application has been converted, because without their help, it’s probably easier and cheaper to rewrite applications from scratch (which is often necessary anyway because of huge changes in API and GUI) for another platform with better support and well-organized community.