Question: why is the source code not available on Github?

[dfreiberger]

I am excited to see initiatives like this project, however I wonder why you are not including the source code of the packages on Github?

It is nice to be able to browse the code, share links to specific lines of code with other people, fork the project in order to submit pull requests, etc.

I am assuming there is a specific reason why, and am just putting this question out for others to have visibility, as I did not see the question already asked.

I understand that we can access the code by adding the library as a project in TwinCAT - but this is not the same as being able to see the code in Github and comment on it.

AB#4657

[FilippoBoido]

I agree, please upload the code on Github in order to make it possible for the community to fork or make pull requests.

[nshiggins]

We have considered, but ultimately we are a team of project engineers and not full time developers concerned solely with the framework. It takes a considerable amount of time to review pull requests, investigate bugs, verify backward compatibility, etc. and we are often fully utilized on project work.

[FilippoBoido]

Maybe we could help with a test framework. Uploading the code would make it easier to contribute and is in the interest of everyone. Noone puts a timeline on how fast you need to review pull requests etc..

[runtimevic]

I join this, the source code should be available so that the entire community can contribute...

[dfreiberger]

@nshiggins I think that people would understand if there are not resources to review pull requests (this could be stated in the main readme). It is not ideal but there are many projects in this state on Github, I think people still appreciate being able to see the code, and they can always fork and make changes on a fork if they want. You can also add explicit requirements around contributions that help to filter out any PRs that don't meet those requirements, and perhaps the community can assist with the review process.

[shanereetz]

@dfreiberger I understand the full scope of the question is much larger, but thought this may be useful regarding your point about browsing the code.

Because SPT provides these libraries as .library files instead of .compiled-library format, one can actually view and debug the source within TwinCAT. From InfoSys: *.library (source library) You can open a source library (for viewing and/or editing) by using the Add Existing Item command, which is available on the PLC node within the project tree. You can "step" into a source library using the usual debugging function.

For simple viewing, I find it easiest to add the library to a project's References, the double click that library, find the POU / DUT in question and double click that.

[dfreiberger]

Thank you @shanereetz. I think my main point was more about being able to use the features of git with SPT, for example to fork / contribute / comment and link to code.

Given the license on SPT is MIT, I guess that anyone could fork this repo and add sources to it, but they would always be trying to manually match the current code on this repo. I assume Beckhoff USA is using git for managing this library internally, but has just chosen not to make that repo public.

[corygrant]

@dfreiberger I imagine the main issue is support. With a controlled source the Beckhoff support team can support your application. If the source was open they would have no idea what you've modified.

For me, having the Beckhoff support team available to help is more important than having editable source.

[nshiggins]

Sorry that this issue went stale for so long. We discussed this at length both internally within the team and also with management.

The framework began and continues to primarily serve as a common codebase for our team to quickly commission machines which we have been contracted to develop, and to be able to plug members of our team into and out of projects with minimal 'coaching'.

The fact of the matter is anyone interested in using this framework is very likely to be a paying Beckhoff customer, and that opens the door to potential issues. Example--a customer wishes to contribute their super cool function block, but it fails to meet the design pattern (hungarian notation, etc.) doesn't work right, conflicts with existing capabilities, etc. We don't want to be in a position where we might have to tell a customer that their code is no good.

What happens if someone contributes something that is their employer's IP and--unbeknownst to SPT--Beckhoff has a legal agreement in place that assigns ownership of the final product to the employer? Yes, the framework is MIT licensed and we would be likely to prevail in court if someone claimed the framework as their own but litigation is bad for customer relations in any reasonable sense.

It's just not worth the potential issues.

We are of course humbled that what we've created is interesting enough that outside resources would be willing to donate their time to contribute.

On Mon, Apr 15, 2024 at 2:27 PM David Freiberger @.***> wrote:

Thank you @shanereetz https://github.com/shanereetz. I think my main point was more about being able to use the features of git with SPT, for example to fork / contribute / comment and link to code.

Given the license on SPT is MIT, I guess that anyone could fork this repo and add sources to it, but they would always be trying to manually match the current code on this repo. I assume Beckhoff USA is using git for managing this library internally, but has just chosen not to make that repo public.

— Reply to this email directly, view it on GitHub https://github.com/Beckhoff-USA-Community/SPT-Libraries/issues/34#issuecomment-2057550675, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMHY7N3ZO5K56RUUUBF5LTY5QLZ5AVCNFSM6AAAAAA7TSGILOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXGU2TANRXGU . You are receiving this because you were mentioned.Message ID: @.***>