Re: Hello World!
|
Mark Gisi
Hi Jeremiah,
>>> Secondly, I have some concern around cadence.
I am ok with either a weekly or biweekly cadence.
>>> Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners.
I generally agree. One point I expressed at Tuesday’s meeting was that we need to focus on requirements (the what) and not specific processes or tools (the how). Different organizations will likely want to invest differently in processes and tools. As long as an organization can satisfy a standard set of requirements they should be good. We might provide example implementations or perhaps recommend certain technologies, but the effort should largely be requirements driven, and process and tool agnostic.
Taking off my OpenChain hat and putting on my SPDX hat - being one of the largest producers and consumers of SPDX data and an active participant in the SPDX working groups, I feel somewhat obliged to provide additional clarification on SPDX. I will do so in a separate email thread to avoid distracting from the spirit of your points.
- Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster
Sent: Thursday, August 28, 2014 1:40 AM To: openchain@... Subject: [OpenChain] Hello World!
Hello,
Firstly, and most importantly, I'd really like to thank those who've done the organization and brainstorming to get this list and idea off the ground. I know there are a lot of people behind the scenes at the Linux Foundation and other places who've done a lot of important work. Thank you.
Secondly, I have some concern around cadence. Telephone meetings once every week require momentum, otherwise its just a bit of conversation and while that is always good, it doesn't show much progress. I'd recommend once every other week unless its demonstrated that more is needed. If we stick to once a week, the project will likely have to have some project management -- milestones, deliverables, deadlines. There are already a lot of resources for people to discuss compliance, FSF compliance lists, FSFE legal, Debian-legal, etc. We don't need another list, we need codified methodology that's widely accepted both de facto and de jure.
Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. For example, while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development) and feels a bit like a solution looking for a problem. Being Java based (there is Go code and python code now) its better suited for those working in a Windows environment and while I'm certain that is a highly lucrative market, for Free Software developers it tends to be anathema. If SPDX is the right and only ISO certifiable solution, we ought to be able to demonstrate that in detail and with strong technical and legal support.
To be successful, you'll have to be widely adopted. This is the exact same measure of success FOSS software projects have to meet. The recent migration of systemd into Debian forcing Ubuntu to migrate away from Upstart ought to be a cautionary tale: forks often fail.
Please don't fork the compliance process. Please make it better, standardized, and transparent.
Warm regards,
Jeremiah
-- Jeremiah C. Foster GENIVI COMMUNITY MANAGER
Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18
M: +46 (0)73 093 0506 |
|
|
