On May 18 2013 12:51 AM, Michael Haberler wrote: > Am 18.05.2013 um 04:36 schrieb Matt Shaver <m...@mattshaver.com>: > >> On Fri, 17 May 2013 08:50:36 +0200 >> Michael Haberler <mai...@mah.priv.at> wrote: >> >>> If anybody wonders about the above: I am super-pissed about the >>> utterly unprofessional behavior of the past board on the issue. >> >> For a background on how the board was created, see: >> >> http://linuxcnc.org/index.php/english/component/content/article/15-events/18-emc-fest-2004 >> >> There are a number of things which should help you understand how we >> got where we are, and why things are the way they are: >> >> 1. Ray Henry, who proposed and championed the Board of Directors >> idea >> in the first place, also wanted a non-profit organization set up >> that >> would accept donations of money or equipment from commercial users >> of >> the EMC software. This money would be used to pay for the web site, >> and >> to pay developers to write code if required. As I recall, John >> Kasunich >> was very opposed to the idea of adding money into the project, >> fearing >> it would cause more harm than good. In retrospect, I think he was >> right. Who decides what is fair? > > I dont think the issue of money being thrown onto the LinuxCNC > project has been a major problem so far; but if that happens, I am > sure there are ways to funnel funds in a way such that a an entity > fit > to engage in commercial transactions is not required. > > Then, let's cross that bridge when we get there.
in a way we have already crossed it, and the backlash from the community was in part what caused me to become a lurker for half a decade... There needs to be a mechanism that allows people to pick up paid work and then give back source code/changes to the community. I think that actually exists, but then there is the issue of what functionality a company wants/needs implemented and how the LinuxCNC community will interact/accept that. There is a separate issue of funneling money from a granter to someone doing the work which can get into some hairy leagal paperwork issues, but those things can easily be worked out if you do not mind just paying the tax. Establishing a NPO to handle this is possible and some might already exist that would be willing to support funneling money to cover costs of server hosting and the like. >> 2. Also, the original main purpose of the board was to provide a >> central point of contact for inquiries. There wasn't really the >> intention (at that time) for the board to direct the course of >> development. There were a lot fewer developers back then, and they >> had >> their own collaboration methods, mostly e-mail on the list. > > That's the very issue: the scale of the project has changed > considerably, but the model how to run this has not adapted, and is > now defunct Central point of contact (CPOC) may be what people expected, but CPOC for what exactly. This should not include everything people can dream up to ask. Having a CPOC (which is basically an education and public outreach person) is a full time job even for something like LinuxCNC. You might not think so, but just look at how much reading we have all been doing today on the list, and the CPOC's *job* would be to keep up with it all... more later on the position requirements as I see them, and other aspects (such as a separate design team, QA/QC, and doc writers that should be clearly separate from the board per se). >> 3. EBo said, "This is not because they do not care, but people have >> jobs, families, children, and can only do so much." >> This is the crux of the issue. I'd love to have a job where every >> day I >> worked on coordinating development of Linuxcnc in accordance with a >> detailed plan adopted through a consensus of all the interested >> stakeholders in the project. Unfortunately, I also have to make a >> living and no one is going to pay me to do that job (that I know >> of). > > I do not agree on several accounts. > > First, I discount the 'no time' argument for the simple reason it is > the most generic weaselword excuse ever for not getting anything > done. > Anybody standing better be aware that to fulfill role expectations, > time for non-technical issues is required; if this is not doable or > does not fit personal preferences, that is a conflict, but it should > not be resolved by the 'I dont have time' excuse, followed by 'oh > well'. > > Second, having been on my more than fair share of boards, I dont see > where the concept of a super-time eating board role comes from - > contrast that with the status quo, where I am a bit pressed to find > support for that argument. > > I will outline my views and expectations of a board in separate mail, > but one thing is for sure: I primarily view this to be a steward > role, > which includes moderating processes, act as a decider of last resort, > and act as a keeper of timelines (yes, you heard the 'd' word ;-) I was about to cry unmitigated BS! until you wrote that the board's role was [organizational] stewardship. The 'no time' argument does not come from an expectation that as a board member my only job is to say make sure the electricity bill is paid for the server, the domain name is paid for, the bank accounts are balanced, monimations/elections are timely, ... That is very different than being badgered by "I ***NEED*** (SOME USER SPECIFIED) FUNCTIONALITY NOW, WHY THE $#!$!@# DON'T YOU HAVE IT. WHY DON'T YOU ANSWER MY EMAILS WITHIN 24H YOU UNPROFESSIONAL CADS..." The answer is clearly that it is not their job. No, one of the problems in the past is the board members were expected to know all, and do all -- including shepherding a formal design when they may have not had the training or experience to do something like that. Separating the roles and clearly define both the expectations (minimal things you got to do) and the scope (what are you allowed to do in that position) is necessary IMNSHO. > Those last three items are the ones I see the largest deficits - note > this is a largely non-technical affair: herding cats. I surely do not > see this as a club of micromanaging heldenprogrammers doing > patch-by-patch reviews. fair enough, but if you are commenting on my suggestion of formally regression testing as part of the system design I would add the following: LinuxCNC has a non-trivial potential of *lethality*. Having formal reviews of mission critical sections of the code would be a very good thing. I do not see this as being necessary for each and every section of the code, but you know, there are just some cases where if the software faults, then something or someone breaks. It is one thing when you are using LinuxCNC to run a MaxNC-10, and another when you are driving a CNC plasma rig where the gantry is 16' wide and weighs half a ton (and not this example is not pulled out of a hat). >> A lot of time has passed since the board was created, and the >> situation >> has changed quite a bit as well. There are more and better >> developers >> than ever before. There is much more interest in CNC than there ever >> was, much of this due to the nascent "Maker Movement". > > That is a very good point you bring up. It is very nice to think > about the "Maker movement" and LinuxCNC having a role there. The cold > reality is: this project has largely slept through that particular > window of opportunity. I would not say slept through but thumbed there noses at it -- specifically, the low end controllers that run off of Arduino shields and the like are just good enough to drive a slow 3D printer, but cannot deal with retrofitting something the size of a Bridgeport (well not until recently anyway). This was in part due to the hardware people completely ignoring things like adding motor acceleration to the API. This is beginning to significantly change with high res timers, acceleration profiling, and I do not know what all. They still do not minimize jerk and other things that we would also benefit from, but I think you get my point. This bring up another point of hardware support -- should we seriously think of supporting SOC's like the Arduino for LinuxCNC? It is not that much different than some of the embedded Linux solutions coming out today. Well I mean from an applications point of vew, there is still the issue of all the great tools available... > That has many reasons, but a primary one IMV is the fact that the sum > of individual preferences does not make an appealing vehicle for > others to adopt, and decision making has a lot to do with that > failure. > > I would think though that by a bit of thinking outside the box in > time, it would have been possible to restructure LinuxCNC such that > it > becomes an appealing building block. I am still on that case, which I > call the 'realtime machinekit', but I have no illusions about that > being too late for the first wave of reprap products, and it will > require more restructuring that a bit of individual patching to > address such opportunities. Just think about the uphill battle trying > to use parts, not all of LinuxCNC. 5 years ago I hacked some high-res timer examples for the MakeController with the intention of starting a decent motor controller. Much of what is LinuxCNC is useful on such a platform and would still be very useful if ported to low end embedded SOC's. >> My most sincere desire at this point is to have some long thoughtful >> conversations with you (Micheal, et al) about the future direction >> of >> the project when we get together in Wichita next month. We're in a >> much >> better position now than we were back in 2004, and this may be the >> opportunity to take Linuxcnc to the "next level". > > I would appreciate if folks came forward now with their role > expectations and proposals for a board charter now Treasurer: make sure the bills are paid, keep the books, and let us know what you need for cash to make it happen (even if there is not a tax deductible revenue stream). secretary: keep the minutes of formal board meetings (which should happen at least quarterly, and can be done remotely by phone or internet based conferencing). Tallies/reports on votes. head/president/chair/whatever: officiate meetings (say Robber's Rules of Order). Interface with special projects to make sure deadlines/milestones are met. Special projects: Future Design Team: basically what we are doing on the list -- hashing out a design model, and then eventually documenting it. Documentation Team: manage wiki make sure docs are up to date. Software Engineering Team: implementing the design. Most of the design team should also be here to integrate the two, but there should probably be more people helping to write and maintain code than sculpting the vision Anyway, those are some initial thoughts. I have not really thought deeply about it but... > realistically, I dont see a discussion process by mailing list > converging in time, but better a start than nothing this is just priming the pump. There are many of use who will not be able to come to the meeting in Wichita that can participate here... > What we can do, however, is to use the Wichita event to discuss and > agree on such a charter; I think face-to-face this is possible in the > time window available, and I think we should try to resolve this for > good; when that is on the table it makes sense take the next step, > elections. yes, and as you mentioned before -- defining the job before asking someone to do it. These are not public servants which are expected to do whatever it takes to benefit the community... EBo -- ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
