Curious how you are all maintaining your packages?

I built a package at my current job using my Autodesk ID on my company license. I am now going to be moving to a different company and will have new login credentials. So it seems I will lose access to my package and my forum history?

@solamour @emrullah.yildiz @achintya_bhat this is a possible oversight in the package manager process.

@J_Sanford please send a DM to the Dynamo team members CC’d above, from your current package author ID’s email so we can take action without exposing any personal information.

Thanks!

1 Like

Maybe doesn’t apply to you but…
If you use company software, regardless if you do it during company hours, that company may have some rights over the work?

2 Likes

I mean it was primarily created with a free version of Pycharm and most of it was written over thanksgiving vacation 3 years ago. I can see your point, but I would ask- when was Rhythm started as a package? I know John Pierson has changed jobs a few times since its initial creation and is currently an Autodesk employee. So does Parallax team own Rhythm?

Edit- I ask this rhetorically. Of course John is the owner of Rhythm, and my thanks to him for explaining something of the life cycle of his package.

1 Like

It depends on various circumstances. For example, your employment contract, licencing terms and the laws in your country.

It was a friendly, “be aware” message.

3 Likes

First, Rhythm is not owned by Parallax team or by any other company. So to clear that comment up immediately here is a brief history of Rhythm.

Oh and before I get into the background, I want to make it incredibly clear that:

These statements below are my own opinion and do not reflect those of Autodesk or any other entity mentioned in the history below. Also, none of this is meant as negative or anything, its just that the bluntness of your comment raised my eyebrows and I felt the need to reply.


Start of Rhythm

Rhythm was started while I worked at an architecture firm, Dekker Design (formerly DPS Design). At first it consisted of workflows for the firm and my Autodesk ID was attached to my firm’s email account.

When it came time to leave, I met with my BIM manager and we worked out a deal, where I managed to keep the package under my authoring powers and “ownership” if you will. For the first few years after I left, I was required to have a disclaimer that stated, “This package was originally started at DPS Design” and a few other links to the site. I also made sure to switch my Autodesk account’s email to my personal Gmail.

Growth and Development

After leaving the architecture firm, Rhythm was developed by me primarily in my free time, using my own resources. This includes:

  • My personal laptop
  • My own Revit license

During that first year, I did develop another package (Beaker) for the company I worked for at the time, and that package was 100% owned by them. WIth that in mind, that package was built on company resources.

Parallax

Parallax is incredibly generous, as you may know if you have seen Aaron’s contributions on the RevitForum. While at Parallax I added nodes that Aaron and the team directly needed to get mission critical work done. This resulted in a mixture of my own time and company time to add stuff. But this was worked out up front and in my employment contract.

Rhythm’s Future

I still maintain Rhythm, but I do add less stuff to it these days. It deploys from Github and I use my own resources and time to do so. I do use Rhythm as a test bed for stuff too, but either way, the separation is there. Additionally, Rhythm has a disclaimer on the Github and the package manager.


I hope that helps out and clears things up, but I do echo @alien’s comments that being transparent and upfront about what you are working on is of utmost importance.

Also, for reference, if you have a question on how a package works or ownership concerns, feel free to DM me directly as I didn’t really expect to read the “does Parallax own this?” on the public forum.

3 Likes

My apologies, I meant it as a rhetorical not literal. I never doubted that Parallax did not own Rhythm of course. My situation is similar in that it started as a blend of personal time and company time. It never occurred to me to maintain my own Revit license and account full time just so I could have unambiguous intellectual rights to my work, but it seems that this is what you are indicating I should be doing in the future.

2 Likes

No worries, my response definitely was because there are so many interesting discussions that could be had regarding stuff like this. :sweat_smile:

I did used to have a post for “best practices” for package authors but my old blog is offline. I can try to dig it up, but here are the bullet points I had:

  1. Build with no dependencies on package manager-based packages. Dynamo handles these very poorly and it creates a terrible end-user experience. Note: This is not the case if you are sharing a workflow (DYN) that is bundled as a DYF that you want the person to be able to get the dependencies for.
  2. Publish your Dynamo package with an email that you plan on having access to for the foreseeable future. ***Gmail is forever, work emails are not.***Note: This has became more difficult recently with Autodesk SSO. You cannot simply login to another account and all is well. If you are running into these issues you are able to contact the Dynamo team directly to setup multiple emails to manage a package.
  3. Versioning is very important. Decide on it up front because it does matter. There are several ways to do this. A few of the most popular are:
  • Semantic Versioning 2.0.0
  • Calendar Versioning
    Personally, I use calendar versioning for Dynamo packages. If I published a version of Rhythm Feb 2, 2021 it would be, v.2021.2.1. Reason being, it is my first release of Rhythm this month of this year. 2021 is the year, 2 is the month, and 1 is the patch number, (not the day of the month as it may seem).
    The important thing with version is to pick one and stick with it. Dynamo’s package manager will not allow you to start with Calendar Versioning, “2021.1.1” and switch to Semantic Versioning, 1.0.0 because 2021 is technically a “higher” version. :unamused:
  1. For Zero-Touch Developers: Never bundles DLLs in your package that the host software already loads. This includes items like the RevitAPI or any of the Dynamo DLLs. This will raise all sorts of errors in Dynamo and can result in crashes.
1 Like