15.1.5 C# SDK project missing from the Rest API library?

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?

Parents
  • I agree. Perhaps a “limited source code agreement” of some kind could be developed for the benefit of the community? Something that would only allow for upstream integration and approval perhaps?
     
    In the open source world, there is a concept of a “maintainer”, who is a developer and referee when it comes to keeping the code up to date, making improvements, and also (and crucially) accepting code from contributors. I think we all want a better product, but preventing those who use it and can improve it from doing so doesn’t make a lot of sense.
     
    The closed source approach with the APIs has already hindered my ability to figure out what’s going wrong when something doesn’t happen the way I expect, because I can’t see the underlying stored procedure. Whereas with SOAP, I can go down that low if needed to understand what the parameters are and what they’re doing, and why they’re needed.
     
    Please reconsider your decision. I’m not saying 100% open source the code, rather, I’m looking for a compromise so that those of us who have paid for the binaries can access the underlying code, but also protect the rights of Tessitura.
     
     
    Russell Hires | Web Developer | russell.hires@strazcenter.org
    David A. Straz, Jr. Center for the Performing Arts |
    1010 North W.C. Macinnes Place | Tampa FL 33602
    O: 813.202.1570 F: 813.222.1057
     
     
     
  • 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!

Reply
  • 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!

Children
No Data