We are planning to upgrade Tessitura for one of our clients and found out that the C# SDK only includes the DLL and not the project like this (https://www.tessituranetwork.com/REST_v151/TessituraService/LIBRARIES.HTM) is that an intentional? If this is not intentional, how can I download that?
This is intentional and will be the case going forward from 15.1.2. The compiled dll is a result of a large amount of user feedback asking us to release the sdk as more of a product and less of an example code library. There are other enhancements included as well, including logging, telemetry, interfaces, and .net standard library packaging supporting both .net framework and .net core.
You should be simply able to include a reference to this dll and remove the old project files. We are looking at releasing this as in a myGet stream in the future if adoption warrants it.
Hope this helps.
Dave
This is a huge step backwards. There is no reason that the SDK cannot be released as a compiled product as well as open source within the Tessitura community.
I hope you will implement the myGet stream for source code access and/or provide direct access to both the compiled SDK as well as the source code in the Tessitura Services libraries. As you know, software does not always run correctly. Not having access to source code limits developers' ability to diagnose issues. Software is not ever complete. What was considered complete in 2005 is no longer useful today. Limiting access to source code limits the ability of developers to enhance and extend into the future. And documentation is rarely if ever complete or sufficient. Access to source code is the most transparent way for developers to learn expected behavior.
It looks as though the Java source code is fully available, the Android source code is fully available, but the C# source code is not. I hope you will reconsider this decision and continue to provide access to source code for the all the SDKs.
Thank you -- Alan
As the originator of the SDK sample code project I want to take a moment to clear the air a bit and offer a little historical perspective... The SDK has included code examples of how you might interact with the API in raw source form for some time. This was always intended to be a starting point or learning tool for developers, not production code. After several releases where we were asked to formalize this and create a product for at least the C# version we agreed to do so and this is what is now available. It is also very important to understand that this is not, nor has it ever been open-source code. This is the result of a dynamic code creation project that runs internally on our build servers when code is committed. That is important because it means that the community could not contribute changes to the source as they would need to be made to the code generator and not the resulting code. This is true for all of the offered languages.We have had several instances where developers have taken our sample code, edited or extended it and then grown frustrated when trying to move from version to version against this code model. We have always tried to explain that supporting that approach with this type of generated project is really not feasible. That is one of the main issues that moving to a compiled source intends to help address. All this is to say that I honestly believe that it would not be in anyone's best interest for developers to take this code in it's raw form, make edits, and then push to production. Especially not to then try to manually translate the changes from version to version from the static change log into your code via manual process.BUT...We will re-address the generation and packaging process to allow for both the compiled and raw source to be available in the C# SDK folder going forward if that is what the community wants from the product. As there is a service pack that is code complete as of yesterday I don't think it will make it into this release, but expect it in the next service pack release for 15.1.xPerhaps a more interesting long-term initiative would be for a BitBucket repo to be created where a dynamic code generation project could be created and maintained by everyone in the community. This would be truly community sourced. I am happy to start and contribute to this effort if it seems like there is interest.
Hope this explanation is helpful, but either way, know that we heard you both - and others - and will offer the raw source again in the next service pack.
Agree on all fronts. Thanks Dave.
And I knew I was going to get in trouble using the phrase "open source".
More than happy to pile on to this conversation to say it honestly doesn't make sense to me why the entire Tessitura platform isn't open-source in the first place. (I mean, I know why it's closed-source NOW, but aside from tradition and fear, it has not been articulated to me why this is a sensible business decision in light of the mission statement and non-profit status of the company.)
Open source doesn't have to mean anything other than "the paying licensees of the software can see the source code". You don't have to create a community edition; you don't even have to accept PRs (although why you would turn down free bugfixes I have no idea). Licenses can be defined to say "we still own the copyright on this and any contributions you make grant us a copyright on those contributions".
In the early days of enterprise computing, delivering source code with executable binaries was standard for proprietary software, but as software subsequently became a highly profitable industry, fear and greed led businesspeople at for-profit companies to shift the "standard" for commercial development to closed-source. I think this idea of a standard for software development is what continues to inform the Network leadership today.
Crowded markets with high-volume, furious competition lead naturally to better-quality software outcomes for consumers. This is simply not the case for Tessitura's market, nor is software quality the main value proposition of the Tessitura Network in the first place (it's the community and ecosystem). In light of that, it should make sense to shift to open-source development solely as a driver of software quality.
Consider a couple of straw-man thought experiments. Let's say a competitor got a hold of the source code, and we lived in a world where there was no legal copyright protection. Can we honestly say that there's even a single software algorithm within the Tessitura source base that could be considered novel or "patentable"? The utility of Tessitura is to combine together a large number of standard "lego block"-style software components (relational tables, forms, templates, visualizations) into something resembling a cohesive whole. Any competitor with an existing system already has access to the standard components, and all of the "glue" isn't useful to them, on account of glue code not being interchangeable between systems!
Alternatively, let's imagine that the code was released with a highly permissive license that allowed a competitor to fork the entire project and develop a closed-source alternative that started out identical to Tessitura in every way. Would they be able to provide a better product with better support for the same or less cost? What if they could? Wouldn't that just end up being a net benefit to the world's arts and cultural organizations? Isn't that what we're here for in the first place?
If we wanted to get really radical (and make a move that a Fortune 500 company made a decade ago), we could imagine the source being released under a license similar to the CDDL, which allows for forks and improvements by other parties, with the condition that those improvements be made available under the same license. Then, if some team wanted to get together and fork the project to provide a competing service (perhaps they offer better support for a premium price), Tessitura still gets the benefit of any improvements they make to the software. Everybody wins!
Dave, I just read that
The .NET Standard SDK offered as a compiled package will be the only C# SDK supported starting with 16.0. The legacy SDK built in .NET Framework and offered as source will be retired in 16.0.