Tue 19 Apr 2016

Business Case for each recommendation

Cameron Shorter Public Seen by 358

Firstly, congratulations on developing this policy. It will help agencies be much more effective in their use of Open Source.

Re application: I suggest this document will be more useful if language is used which helps readers define the business value of one recommendation over another.
For instance, giving back a code fork costs time and effort which equates to money. To be done properly, having a feature incorporated back into an open source baseline will typically add 20% to 40% extra effort coordinating with the community. Will this effort cost more than the long term benefit?

Recommendations should be included in this policy to help readers construct answers to these types of questions.

At risk of my comment being dismissed due to blatant self promotion, in my job at LISAsoft we have been supporting the implementation of Open Source for governments for decades, including providing health checks to Open Source development strategies and writing Open Source Policies. I'd love to be approached to apply the same to this project.

Warm Regards, Cameron Shorter < c a mero n DOTshort er A T gmai l .c o m>


Cam Findlay Tue 19 Apr 2016

Thanks for the comments and welcome to the conversation @cameronshorter :smiley:

Interesting perspective and some clarifying questions.

When you say "...define the business value of one recommendation over another." are you referring to selection of licenses i.e. MIT or GPL decision?

Do you have some data to support the 20-40% extra time mentioned? (No problem if this is more based on experience though :thumbsup: ).

Is this assuming working on the code in private and then releasing as a patch to the project or working iteratively in an openly collaborative way during the code development process itself? In my experience as a developer working with open source, I've found the later approach not to add significant development time to project work and I could imagine the former might add time as mentioned.

Interested in exploring this from many perspectives :thinking_face:


Cameron Shorter Tue 19 Apr 2016

Hi camfindlay,

Re "defining the business case", I'm referring to the multitude of business justifications that projects face when selecting one business strategy over another. Should I use one technology or another? Should I use open source or proprietary? Should I work collaboratively as part of an Open Source community and contribute to the development of community features which are not relevant to me, or should I just focus on the one feature I want improving, then throw the code back at the community and hope they take it? Should I use MIT or GPL license? Etc, etc.

The 20%-40% is approximate, based on my personal experience working with many Open Source projects. Sorry, no empirical metrics to back that up.


Cam Findlay Wed 20 Apr 2016

Thanks for the response @cameronshorter appreciate the clarification.


Cam Findlay Wed 20 Apr 2016

Clear business cases and guidance on practical matters are a good to have. What you suggest here would make great guidance notes around NZGOAL-SE.

There has been some other discussions along these lines recently in other threads that the community have agreed would warrant later some practical guidance notes being created.

What do you think? :smiley:

The key thing here is to keep in mind is the scope of the NZGOAL-SE framework is focused around the FOSS licensing processes specifically.


Dave Lane Tue 26 Apr 2016

My concern here is that the "business cases" are presumably focused on the case from the bespoke software service provider perspective rather than the gov't. I think the key thing here is to remember that the customer, ultimately, is the taxpayer, and we must prioritise their interests above the commercial interests of individual suppliers. Otherwise, this system is designed to exploit the commons for private benefit rather than enrich the commons for public benefit.


Danyl Strype Wed 27 Apr 2016

I agree that public benefit needs to be central to NZGOAL-SE itself, being an advisory to government departments and other public agencies. I think there is value in what @cameronshorter suggests, which I interpret as a set of advice for businesses about how to participate more actively in the development of the software they use, but from the questions he asks, it seems to me the scope of this is either beyond (eg Should I use one technology or another?) or totally outside (eg "Should I use open source or proprietary?") NZ GOAL-SE.

Of course, that doesn't stop anyone interested in helping develop such a resource from discussing or even organising it using this thread. Anyone who isn't interested doesn't need to comment or even to follow this discussion. This is one of the benefits of Loomio over having this whole consultation over an email list :)