13 Replies Latest reply on Feb 15, 2019 6:32 PM by Rick Davin Branched from an earlier discussion.

    OSIsoft's GitHub Policy update: A sad state of affairs

    Rhys Kirk

      Such a sad state of affairs when such useful stuff gets pulled for bureaucracy.

      Sigh.

        • Re: OSIsoft's GitHub Policy update: A sad state of affairs
          Rick Davin

          As one of the many contributors of the pulled GitHub code, I do want to chime in.  Thanks for the "useful" plug - I agree.  But I disagree that it was pulled for bureaucracy.

           

          The notion of GitHub - or really let's expand the discussion to FOSS (Free and Open Source Software) - was that it was for community involvement.  OSIsoft employees and customers alike could share code and jointly work on a project.  That implies a 2-way street.  What actually happened over the past 3 years is that virtually 100% of the FOSS was created by OSIsoft employees, and the only customer participation we witnessed was nothing but download-and-consume.

           

          Again, myself and every one of my teammates was affected by the decision to restrict access to GitHub.  It's easy to mumble under our breath and complain about corporate decisions, but I do understand some of the reasons behind the decision.  And not because a superior told me.  Rather, my change of viewpoint came from a prominent EA customer who said they would only use a PI Vision 3 symbol if it were officially supported and guaranteed to be offered as a PI Vision 4 symbol.

           

          That's when it hit me.  Customers were not viewing GitHub as a developer's playground where ideas get incubated and you can collaborate over some cool code.  They saw it as an alternative download platform to Tech Support.  Worse than that: they saw it as an officially sanctioned download alternative - and this is absolutely NOT the case.  The products officially offered through Tech Support Download have been put through rigorous tests.  They come with a promise of working as best as possible with many older versions.  They are officially supported if you call Tech Support for help.  And they come with a promise of working in the future.

           

          And that's the problem with FOSS.  None of our GitHub offerings came with any such guarantees or promises.  Here's what I can tell you about any of my code contributions.  It worked on a specific version of Visual Studio, with a specific version of .NET, with specific versions of AF Server, Client, and PI Data Archive.  I never bothered trying any regression testing or worried about compatibility with older versions of PI Server.  Nor would I ever think of going back to update my FOSS when a new version of PI Server is released.

           

          Our customers are used to having our official products supported thoroughly.  We rank high in customer satisfaction with Tech Support.  The best that could be said over our GitHub contributions is that they seemed to work successfully for the author's development environment.  That is a very low threshold to pass, and it is far too low for customers who mistakenly considered GitHub as being official. 

           

          So, no, GitHub repos were not pulled in the name of bureaucracy.  They were pulled because they created too much customer confusion regarding support.  Too many people felt GitHub repo's, whether authored by an OSIsoft employee or posted under the osisoft account, were somehow supported.  And that they would continue to be supported in the future.  It was a shock to many when we pulled the repo's.  It was a bigger shock to many when told them the GitHub repo's are not supported at all. 

          3 of 3 people found this helpful
            • Re: OSIsoft's GitHub Policy update: A sad state of affairs
              Rhys Kirk

              Thanks for the lengthy reply.

              Whilst I appreciate the points you raise I still don't fully agree with them (I think). It's getting late here.

               

              GitHub started in 2008, 11 years ago. It isn't a new concept and many organizations embrace it.

              What it feels like is that an EA customer(s),  someone who pays OSIsoft a bunch of money, raised the confusion and so rather than educate customers and the like on the open source world, the knee jerk reaction was to pull everything and eventually sort it out (already 3/4 months).

               

              Anyway, didn't mean to hijack this post.

              2 of 2 people found this helpful
                • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                  gregor

                  Hi Rhys,

                   

                  I have branched the comment you initially posted as a reply to R Library into this new thread because I believe it is important having this discussion about open source software within the PI Developers Club community.

                  • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                    Rick Davin

                    Rhys,

                     

                    As Gregor has moved the discussion into its own thread, we may continue to have a healthy dialogue without hijacking someone else's post.

                     

                    I hear your frustrations and share them in large part.  You and I know each other personally, and you know I was a customer for the life of vCampus, and vCampus Live!  Boy do I miss those days of a vibrant community chock full of ideas.  Some led to bigger things.  Other ideas fizzled.  But there was a wonderful spirit of cooperation and innovation coming from the developer community - most of which were EA customers and/or partners.  If you believe this article, two priorities from our customers are Open Source and Innovation.  vCampus and later GitHub helped towards those customer priorities with regards to the developer community.

                     

                    But that developer community has been and always will be a small (but vocal) minority.  If you take a look at PI Square as a whole, or PI World registrations, people self-identifying as developers make up only 5-10% of the population.  If GitHub was limited to just those developers, you know the movers-and-shakers who understand the spirit of FOSS, perhaps OSIsoft would not have been so restrictive in pulling repositories.  The problem is the other 90+% of PI users who are not developers but hear of something useful on GitHub.  These people don't know about the spirit of FOSS, and more to the point, they don't care.  They've heard of something useful out there, and go to grab it.  They see it posted under the osisoft account or by an OSIsoft employee, and will never attempt to understand what the Apache 2.0 license means.  They just say to themselves "Someone at OSIsoft posted this, so it must be official."

                     

                    And I do strongly feel that the 90+% who are not developers should not be grabbing FOSS that they do not understand why it written, how it was written, what problem it solves, or its limitations.  And, oh yeah, how its not supported.

                     

                    So we are faced with either upsetting 5-10% of the developer community, OR with the herculean task of educating 90+% of non-developers about GitHub and FOSS.  There is no happy medium here.

                     

                    Here's my take on the developer community.  And I held this belief while I was a customer, and still do as an employee: You can divide the PI developers into three tiers.  The top tier (where you sit), can get by without our GitHub contributions.  This tier contains the leaders of the developer community.  Sure, the GitHub repos can help save you some time, but again, you can live without it because you can write it yourself (and sometimes, write it better).

                     

                    The bottom tier are struggling developers.  They really want the easiest way out and would love to be spoon fed the solutions.  GitHub contributions are crutches to this tier, and as long as we provide them those crutches, I do not see them growing in skills.  Let's face it, we share code on GitHub, and this tier never bothers to study and learn from it.  They simply plug in it and try to use it  The first sign of any hiccup, and they are lost - and wind up screaming for us or AT us.

                     

                    The middle tier is capable developers who do need helpful, useful examples.  Unlike the top tier, they may not be the pioneers with the developer technologies, but unlike the bottom tier they are willing to study the code examples and learn from them.  Out of the three tiers of developers affected by yanking GitHub repos, this tier is the one for which I offer my condolences. But this tier is a subset of an admittedly small minority.  What can be done to help this tier?  For starters, non-OSIsoft employees could post their own FOSS examples.  There's nothing stopping that from happening, right?

                      • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                        gregor

                        Rick Davin wrote:

                         

                        So we are faced with either upsetting 5-10% of the developer community, OR with the herculean task of educating 90+% of non-developers about GitHub and FOSS. There is no happy medium here.

                         

                        The German Basic Law aims for the protection of minorities and I believe we Germans have this in common with other modern communities. So it is not just us

                        The Apache 2.0 License, which we use(d) when sharing open source projects clearly states that contributions are offered "AS IS". The fact that single individuals does not pay attention to the license doesn't cause the license to not apply. Assume a few individuals don't pay attention to the SLA and ask to be served tee and cake each afternoon just because they claim it was their assumption this is included.

                         

                        Sorry, I couldn't resist but let's get serious again. To my understanding, we are covered with the Apache 2.0 License in place.

                         

                        Educating community users on how to use our products is our mission anyhow. Let's be positive about educating community users who don't understand open source concepts. I am pretty certain those community users understanding the value of open source will support our efforts too.

                          • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                            Roger Palmen

                            So i think we can agree we could bring some form of source sharing back, but then limited to the developer community?

                              • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                                Rick Davin

                                Not so much limited to the developer community.  I think the better word would be targeted.  Take the best of vCampus, where code posting was in the spirit of educating the developer community.  The intent was to point developers in the right direction, show them proper use of methods, as well as best practices.  Then we get out of the way and let them run with it.  All that helped improve the skills of the developers because it was left to them to incorporate whatever bits and pieces worked best for their own solution.  Let's continue to do that!  When we show code, and I am using the collective WE as in customers and OSIsoft alike, let's wrap it inside a learning experience.  But the final solution to solve a customer's specific business problem remains totally up to the customer developer.  As it should be.

                                2 of 2 people found this helpful
                      • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                        Roger Palmen

                        I don't really feel the need to comment on the debate. I can truly understand many sides of the arguments. Yes i've seen the requests for techsupport or fix my problem with the code i just downloaded from github and that's not what it was meant for.

                        What i am really wondering, what would be an alternative?

                         

                        Is posting sample code in a blogpost on PI Square also FOSS? E.g. the custom symbols on PI Vision really made it possible for me to jumpstart my own custom symbols. That is a one-way street, as a customer pays me to produce the 'ínspired-by' code and thereby i don't own it, this no FOSS unly fuss...

                        When i take some code snips from a blogpost of from StackOverflow, is that abuse of the sharing? For code snips this is ok, but for bigger projects it's not that handy.

                         

                        That's why i liked the more closed DevClub in the past. It's not as open as GitHub which is seen as "hey, we from OSI have some free stuff to download', but more like a stackoverflow where you find ideas and ways to build upon. I understand the pullback (no, still don't really like or fully agree), but what i am missing here is a way forward. How to unlock the potential of the knowledge available within OSIsoft?

                        4 of 4 people found this helpful
                          • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                            Rick Davin

                            Hi Roger,

                             

                            Thanks for expressing your opinion.  It does matter to us.  When I was a customer, one thing I deeply appreciated about OSIsoft is they wanted honest feedback from me.  And boy, did I sometimes give it to them!  There would be a lot of love in the vCampus forums, though sometimes it was ... well ... let's call it a harsh love.

                             

                            Sample code on PI Square does fall under FOSS.  In general, what you see in a post is a method or scattered pieces of methods.  What you should continue see, both on PI Square and GitHub, is code intended to be educational in nature.  Maybe it is demonstrating newly released methods.  Maybe it is showcasing best practices.  Things like this will still be offered in the spirit of learning

                             

                            What you won't see is complete packages.  And this means more than NuGet packages, executables, or DLL's.  When we provide a fully functional "click once to run" application, we just killed a prime learning opportunity for developers.  So you won't be seeing fully functional tools or utilities.  But you will see part(s) of a whole.  This then requires a developer possess (1) the requisite toolset (e.g. Visual Studio), and also (2) a minimum skill set to "wire together" the pieces we present.  By doing it this way:

                             

                            • The customer has engaged in a learning experience,
                            • The customer is exposed to new things or new techniques,
                            • Since the "wired together" project is created by the customer, the final application is owned by the customer, for him or her to support, and finally
                            • The customer can also take pride in understanding the finished tool they just created that helps them solve a particular business problem.
                            3 of 3 people found this helpful
                            • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                              gregor

                              Roger Palmen wrote:

                              Is posting sample code in a blogpost on PI Square also FOSS? E.g. the custom symbols on PI Vision really made it possible for me to jumpstart my own custom symbols. That is a one-way street, as a customer pays me to produce the 'ínspired-by' code and thereby i don't own it, this no FOSS unly fuss...

                              When i take some code snips from a blogpost of from StackOverflow, is that abuse of the sharing? For code snips this is ok, but for bigger projects it's not that handy.

                              Please allow me to clarify. When we started OSIsoft's presense at GitHub we worked together with our Legal department and identified the Apache 2.0 license as appropriate, also because it is pretty permissive. I don't want to quote single paragraphs out of the Apache 2.0 License because the license as a whole applies and I also prefer sharing the link rather than quoting the license completely. I suggest you to pay special attention to "Grant of Copyright License", "Redistribution" and "Disclaimer of Warranty" because to my understanding they are key to understand what's permitted and what the level of support is. To avoid any misunderstandings, the Apache 2.0 License applies completely - not just the paragraphs referred to above.

                               

                              PI Square and PI Developers Club as a space inside PI Square are not law-free areas. PI Square Terms of Use and the PI Developers Club Agreement apply.

                                • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                                  Roger Palmen

                                  Aside from the very grey area of "derived works", the Apache license does allow to derive closed source, as long as the other statements are met, that parts of the code fall under apache license. Which is to say the least, not really forcing anybody to make derived works available under the apache license too.

                                   

                                  But i think the discussion is not about the legal terms, but on the practice that is observed. Either terms of use, licensing terms not honored, and not a compelling reason to chase for litigation makes the current practice quite different from the legal perspective.

                              • Re: OSIsoft's GitHub Policy update: A sad state of affairs
                                Roger Palmen

                                I just thought about a good case against FOSS in the world we live in.

                                We have a customer which does a great job in building and maintaining a domain-specific analysis package on top of PI, and sharing that on GitHub. Now a company comes around, tries to sell their own code as a proprietary software, and they need to take legal action for the product to be pulled back from sale.

                                That's not the idea behind FOSS, but that is the reality we need to deal with sometimes.