In this article, I want to share my thoughts on open sourcing the Web SDK for Sage 300 and how, in my opinion, this will benefit the Sage 300 Ecosystem.
Let's start by first defining what Open Source Software (OSS) is:
Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose. Open-source software may be developed in a collaborative public manner. Open-source software is the most prominent example of open-source development. (https://en.wikipedia.org/wiki/Open-source_software)
We are planning to use the Apache License 2.0 for our OSS as it allows for use of the source code for the development of free and open source software as well as proprietary software. The license can be found here: http://www.apache.org/licenses/LICENSE-2.0
We are planning to use a GitHub repository for the storage, source code management and collaboration of the OSS. Internally, Sage 300c uses GitHub repositories for its web source code.
I want to first state that there are two SDK’s for Sage 300:
The initial SDK has numerous utilities and tools for generating business views, macros, analyzing data, viewing business view configurations, etc.
Only the new Web SDK will be open sourced.
The Sage 300 ISV and Business Partner community is very active (and vocal too!). This was very evident to me at the recent Business Partner Conference in South Africa where I met with numerous companies and individuals. Their applications, add-ons and plug-ins to the Sage 300 application are very exciting and are part of the community life blood. They have used the existing SDK to build their applications and have enabled compatibility with Sage frameworks and the Sage 300 application.
With the new MVC paradigm, this community will need to re-write their applications for our new Web UI screens. The SDK will provide assistance in getting screens developed quicker by creating Visual Studio Solutions based upon the structures that Sage 300 uses internally. It will also generate code for a screen based upon a business view or a report or a dynamic query, etc. The Code Generation Wizard at this point in time only generates “working code” (it compiles and runs, but only creates the base scaffolding without any “business logic” and only key fields, finder, and action buttons (Save, Delete, Create New)) for a basic setup type screen. The other types of screens (reports, queries, dynamic queries, etc.) generate code, but not a working/runnable screen as these have not been fully addressed in the wizard.
However, all tools can only be so much to everyone in order to consider everyone’s base needs while providing a tool that is easy to use. OSS will allow the community to extend, enhance and tailor the SDK to their specific needs. I believe there to be quite a bit of excitement around this OSS endeavor.
The new Web UI screens have certainly created a lot of excitement for the Sage 300 product and its future. Sage wants this community to be successful in the conversion/re-factoring of their products to the new paradigm. The open sourcing of the SDK will allow those who wish to contribute to the SDK to do so in a way that not only addresses their needs, but potentially the needs of others as well. With this participation, we hope to have a couple of outcomes:
There are numerous policies and procedures for OSS in terms of contributions, accessibility, versioning, release cycles, etc. We have not chosen a specific one, but when we do, it will be something that is fairly lightweight, managed by the Sage 300 Framework Group, follows regular release cycles, etc. The goal is to allow the SDK to be enhanced and extended for not only the benefit of the contributor, but for the benefit of all users of the SDK. Therefore, Sage will perform the approval and merging of the contributions.
I am excited about open sourcing the Web SDK. And from the initial feedback, so is the ISV and Business Partner community. The community will benefit from participating and contributing to not only their success, but to the success of the SDK and to other users of the SDK. Of course, not every member in the community will participate in the contribution process, but this is natural and expected when it comes to OSS. The SDK is a tool to be leveraged by the community as they begin their re-writing/re-factoring journey. And, allowing this community to participate in the success of the SDK while satisfying their needs is not only beneficial but also empowering.
We are targeting a June 2016 timeframe for making the SDK OSS. However, as a standard disclaimer, any topic in this article is subject to review and doesn’t represent a commitment as to when this will be available.
Hey James and thanks for your question. Open Sourcing the SDK will be made available to those who are participating in our DPP program, which is fee based. Therefore, the fee will not go away as this fee is for support and other services.
Does this mean we don't have to pay any development programme fees?