Benevolent dictator or democracy?

Why is the Arduino group organized as a benevolent dictatorship and not in a more open democratic way like Debian Debian Constitution?

The current organization seems to lead to many foul-ups like this String corrupts the heap and crashes - Suggestions for the Arduino Project - Arduino Forum where Paul Stoffhegan submitted a fix to a serious bug but the fix was not properly handled.

Many of us waste a lot of time because of mysterious events like this.

A more open organization with elections for leaders and a technical board might provide better support for Arduino users.

Even more important, this would provide a better path for development of new features in future releases.

Why is the Arduino group organized as a benevolent dictatorship and not in a more open democratic way

Because the Benevolent Dictator created it that way.

Because arduino is a commercial project, so they need to keep the blame internal. Saying "Your project doesn't work because funguy4928 made a bad patch" is no way to run a business.

While the current model isn't perfect, and I've personally found it extremely frustrating on many occasions, one thing is absolutely clear: Arduino is highly successful.

If any changes are made to Arduino's direction, small incremental improvements are probably wisest.

Apparently golden-egg laying geese are best handled with care....

I guess the current model works for them and after all that's all that counts.

I've tried a few times to contact the "team" and had absolutely no response. I was particularly interested in helping with the Due port and was willing to sign an NDA or whatever but my emails/PMs were greeted with a stony silence.

Needless to say I no longer have an interest in helping. Now maybe that won't make anyone lose any sleep and maybe it's all under control but a reply would have been nice, even if just "thanks but no thanks".

Rob

Why not just fork the project to create a parallel but open and more democratic development path? Paul seems to be already doing just that in many ways with his Teensy version of the development environment anyway. In that way, the "Dicatatorship of the Stony Silence" becomes a non-issue. We (the people) can offer them the fixes and improvements as they are developed, and they can accept them, or not. If they think they and only they know how to do "Arduino", good luck to them. Perhaps they can concentrate on a development system suitable for the rankest of beginners, where many bugs don't matter because "after all, it is just an educational tool", and we can all concentrate on what those users will want to move onto once they gain a bit of skill and experience.

The old saying that comes to mind is "sh*t, or get off the pot". Team Arduino aren't doing either -- time perhaps to stop banging on the door.

I'd contribute to the project. Perhaps we already need a separate "Newduino" discussion space. A google group perhaps?

BSD Unix is a possible model. I was at UC Berkley in a computer science research group when BSD evolved.

Ken Thompson and Dennis Ritchie developed Unix at AT&T's Bell Laboratories in the early 1970s. In January 1974 Professor Bob Fabry obtained a Version 4 tape and it was installed on a PDP-11/45 at UC Berkeley.

AT&T corporation saw that Unix was successful and dealing with them became more difficult.

A number of extensions, fixes, and improvements were developed by users of Unix. Bill Joy collected these and released a tape called first Berkeley Software Distribution (1BSD). This was an add-on to Sixth Edition Unix from AT&T.

This process of support evolved until DARPA provided funding to make 4BSD a free open source OS for computer science research.

Development of BSD Unix was guided by an amazing committee:

To guide the design of 4.2BSD DARPA formed a"steering committee" consisting of Bob Fabry, Bill Joy and Sam Leffler from UCB, Alan Nemeth and Rob Gurwitz from BBN, Dennis Ritchie from Bell Labs, Keith Lantz from Stanford, Rick Rashid from Carnegie-Mellon, Bert Halstead from MIT, Dan Lynch from ISI, and Gerald J. Popek of UCLA. The committee met from April 1981 to June 1983.

User support from the Arduino group is non-existent. A first step could be to collect fixes and improvements in a well known place.

This would be along the lines of what Paul Stoffregen is doing, not forking the project.

Some open structure needs to be setup to screen and organize submissions so users can easily find and install what they need.

Another step could be a discussion space as pico mentioned where the main topic is how to organize an open user support group.

FreeBSD evolved from the UC work. This is a key statement about the organization of FreeBSD:

The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. The Core Team is elected by the active developers in the project.

So to have a say, vote, you must contribute.

What it may come down to is that the organization may need to change in order to handle the success it has enjoyed. What started as a small project has been wildly successful and the small core of Arduino gods is unlikely able to handle all aspects forever. There is the coming changeover to the ARM core (yay!) evolution of the existing code, etc.

Sooner or later, the core team will have to set up working groups that focus on the hardware side, software side, etc. to keep the platform relevant, fix bugs, etc. Working groups may also help with improving responsiveness from the leadership team to the users that report issues, the developers that propose fixes, etc.

For the vast majority of the Arduino user base the current system works very well. It would be nice, however, if the folk who go above and beyond just using the Arduino IDE (i.e submitting carefully-coded repairs to bugs) to not only get the recognition they deserve but to see those fixes incorporated quickly into the IDE.

Anyhow, I am super grateful to the Arduino team for the amazing IDE they have developed for our benefit and the general stewardship they have shown. However, what I am hearing is that the Arduino core group is currently not able respond to requests and fixes in a timely and polite manner. That should change.

my few cents worth,

and I will get shouted at , I know,

Arduino is great,
it moved me quickly into PIC programming, and up and running.

BUT :

I soon ran into bugs / warnings that are flagged up in the compiler,
and I have reported them, but there is no sense of urgency from Arduino world.

Conversely, the lib providers I have contacted with bugs, have provide excellent feedback and fixes for bugs that are found.

and as to where the 32 bit version of a arduino is, well.

so a mixed bag.

I wish Arduino well, and try to feed back any features I find, along with suggestion for any fix I can see,
but,

I for one am starting the process of looking for alternatives.

I really like Constantin's analysis of the situation.

After more thought, I think a first step to democracy should be to "Petition the King" for the freedom to setup groups like Constantin described.

For a petition to be effective, you need support from people that matter to the King.

In the case of the Magna Carta it was feudal barons, not little people.

I am not sure who the equivalent of barons are for Arduino, maybe Arduino vendors and people like Paul Stoffregen with products like Teensy.

Any suggestions on how to ask the King for freedom?

I think we are already free (at least, I'm pretty sure I am!)

These bugs need fixing, and the system can and should be made more open, extensible, and suited for intermediate and advanced developers, with or without anyone's "permission".

"Petition" if you must. But I suspect the evident need to keep tight and centralised control of "Arduino" in the hands of (too) few individuals at all costs will doom such efforts.

I say let's simply get on with it.

Perhaps a better question is why the Arduino gods appear so unresponsive to threads / questions / etc. in a directory of their forum web site that specifically petitions them with issues / opportunities / and so on for the Arduino platform. In my mind, whether or not the team decides to leverage the great potential (and deal with the potential risks!) of the greater Arduino community, a first step should be greater participation of the steering committee with the community here on its own web-site.

And if the decision is to ignore the fixes offered by the greater community for whatever reason, I wonder if the Arduino framework is flexible enough to allow programming gods to offer fixes that can be applied independently of IDE iterations. I realize that there are significant user risks here but also figure that the users who feel compelled to apply external patches to the Arduino core code would be willing to live with said risks and know what to do about them.

For example, could the string issue we discussed above be solved by placing a couple of files in a 'library'-like folder - perhaps called 'patches' or some other descriptive name that the IDE will look in first for "Arduino.h" or other files? I seem to recall all sorts of modified core Arduino files being shipped with the Brewtroller version of the IDE, for example, to support the 1284P, which was not yet supported officially. This sort of system would allow folk to experiment and report issues before they are incorporated into the official IDE. Perhaps Github would be a good place to store the files that need modification and a user could download them as a batch. That would also allow a greater probability that the various code fragments play nice with each other.

However, any solution that is external to the core team at Arduino needs some sort of coordinator to avoid / mitigate conflicts within the team of developers developing patches as well as liaising (hopefully!) with the steering committee regarding what patches work, which ones don't etc. and perhaps even be able to offer a alpha version of the IDE that precedes the stable releases. Walking this path without cooperation from the Arduino team is likely to end in failure. So I hope they see the need as much as you guys do to leverage the awesome resources here, get over any NIH hang-ups, and make Arduino the best platform it can be.

It seems that most who have the most problems with Arduino are really at the point where they could be doing their own thing without having to depend on Arduino. Arduino is not going to be all things to all people. There are always going to be those who think that some portion or another could have been done better/ more like they were taught/ more like they would do it/ etc and the whole package would be a lot less useful. There was recently one post that suggested that the whole Arduino IDE should be re-written because he thought it was crap. But he didn't seem willing to take on the project himself. Are you willing to invest the time and effort into Arduino that the creator have? Do you have a life outside Arduino? Do you think they would like to have a life outside Arduino? Think you can create something better?

As with any project there are tradeoffs. Yes, the jumper spacing is a mistake. The team has admitted that. BUT _ to stay backwards compatible they have kept the same spacing so shields will work with the old and the new. When I make my own shields I just cut some pins off an old wirewrap socket and bent a jog in them and it works just fine. So it was a mistake, BIG WHOOP!

Oh - and just because some glitch/bug/whatever is the most important thing in your world, that doesn't mean it is top priority in anyone elses world. I know from my own experience in customer service and field service that their are some "customers" that you are not too highly motivated to respond to. They are rude, demanding, ill mannered and they think the world revolves around them. A customer who interacted with manners and respect would always get better treatment than the one you perceived as a jerk. And I know from personal experience that it is real easy to be a jerk. I am well qualified at being a jerk. It rarely gets the results I want, and often brings out the jerk in others. So then 2 jerks get involved in the situation and it just gets worse. So please think about how you might be perceived. And also consider that someone might already have something started that is relatd to your problem, or the new version is about to be released and they have put the time into solving the problem in that release. Oh - and you are one of MANY folks from around the world using this product, so realize that you are just 1 small drop in that bucket, even though you may be used to being the biggest drop in your bucket.

I have done a little bit with AVRStudio4 because I wanted faster execution and smaller code size. I didn't think that was a problem with Arduino - I was working outside the fairly clear parameters of Arduino.

kf2qd,

A couple of observations. Paul Stoffregen went out of his way to identify a problem, bring the problem to the attention of the Arduino team, and develop a working solution that fixes the problem. I believe that puts him into the 0.1% part of the community that can offer more than mere commentary (like myself, who marvels at the ease of use of the Arduino). His experience has not been positive and there appears to be consensus that the String issue he brought up is real, fixable, and that he fixed it. That the Arduino team decided to deploy his code only partially is something I do not understand, it would be great if they could respond as to the why. But the team is currently absent from this particular discussion.

Their right, BTW. I'm grateful for the team hosting this forum and allowing us to interact in this manner. Never mind the the rest of the community and how helpful and cooperative it is. It allows me to get my projects done without bothering the gods that are steering this platform. But my guess is that the Due transition is taking up a lot more CPU cycles than anyone anticipated. For one, I wonder how they will handle the transition to a 3.3V architecture given the universe of 5V-based shields. That said, it seems to be a lost opportunity to exclude volunteers like Graynomad who know what they're doing from helping the team make the product the best it can be.

fat16lib:
Why is the Arduino group organized as a benevolent dictatorship and not in a more open democratic way like Debian Debian Constitution?

Of course it isn't a democracy.

The answer to this is very simple in my mind: Money/Capitalism.

"Arduino" is not an open source project. It is a business that creates h/w products for sale
wrapped around using open source.
That clear distinction is what creates this type of situation.
Since Arduino is a business it must make money and Capitalism is fundamentally in opposition to
open source. Yes there are ways to make money off open source code/projects
but whenever businesses use open source there must be some unique aspect
tied into it in order for the business to make money off of it.

Also, People have different views on what "open source" means and there are different licensing models
that complicate the situation.
From GPLs v.3 model that is fully "free"/open and does not allow closed source uses to more liberal models
like BSD.

Businesses that want to use open source as a jump start in their projects tend to hate GPL v3 because they
can't keep their end s/w product closed. They tend to love BSD style licensing because they can get the code
and not have to directly pay for it, not have to disclose any changes to it, nor have to publish the source
to their final derivative work that is based on it. BSD is a an ideal model for a business as it allows
them to grab source code and not have to contribute back in any way.

Go look at some other companies and see how they handle open source and make money off things:
Apple with BSD, Google with Linux/Android, Tivo, TomTom.

Arduino lands a bit in the middle. It is a business that has created a set of h/w products (not a s/w project) and chose to
open source everything as a strategy to provide and environment to enable the sale of the h/w products.
(BTW, Apple did this with the original Apple ][ - But not anymore)

Is there really that much difference between how the Arduino team handles its open sources
and the way google handles their open sources?

As a business you have to control you own destiny. Having an open source component that is
community driven would mean that you are now at the mercy of that community which could decide
to move things in a direction that hurts your profits by making things easier for your competitors.

Whining/complaining about their strategy, while it may feel good to vent, tends to accomplish very little.
The way to get a business to change its direction and strategy is to hit them in their wallet.
Bottom line: businesses are "in it" for the money and respond very well to competition
or forces that impact their bottom line.

Want to get them to change their h/w design. Stop supporting their existing designs in the forums
and or continually post recommendations to other 3rd party boards that have the updates/fixes you desire.
Show newbies where to buy 3rd party boards that work just as well or better that are lower cost and explain
to them why these other 3rd party boards are better than the "official" arduino boards.
A good example of this would be to stop telling users how to deal with autoreset issues - point them to
3rd party Arduino boards that have a h/w jumper to disable auto-reset.
Or go design your own h/w and undercut them in their own markets. Places like Microcenter are already
taking product from 3rd party Arduino makers.

For the IDE, stop helping them fix bugs. Go off and help guys like the chipkit guys make mpide the
most ideal IDE usable for all Arduino environments so there is a single IDE that can work on all "arduino"
boards regardless of the actual processor.
BTW, mpide is already up and working today on AVR and PIC/MIPs processors and ARM support
could drop right into their framework.i.e. it would be a very quick and easy task to take the Maple
sources and drop them into mpide to create an IDE that supported AVR, PIC/MIPS and Maple-ARM.

There are ways to compel the Arduino Team to change their ways.
Blasting them or trying to argue with/about them in the forums like in this thread is not going to make much,
if anything, happen.
In order to be effective, you have to do things that will affect their bottom line.

--- bill

I'm not interested in managing and maintaining a fork of Arduino. Teensyduino is meant to be an add-on to Arduino, not a fork.

It kind of is a fork, just a very minor one.
Your installer goes in and modifies their sources "in place" with ifdefs and makes things
"better" when the code detects it is being compiled for Teensy boards.
Some of those changes/modifications could work with the other boards as well.

--- bill

Sorry I asked. I knew better but forgot that Arduino is a little version of Microsoft with much worse support.

I started this topic because of what I found when trying to help a beginner. I thought beginners deserved better support.

Many of the things that bother me will never change. For example millis() ticks every 1024 us, sometimes by two ticks to catchup.

pico is right, get on with it. If you don't like it write your own.

Constantin:
Perhaps a better question is why the Arduino gods appear so unresponsive to threads / questions / etc. in a directory of their forum web site that specifically petitions them with issues / opportunities / and so on for the Arduino platform.

I was initially frustrated that the developers appeared to ignore their "own" forum until I discovered the Google Code section set up for reporting bugs. Reporting bugs there at least seems to get a response (say, within a week or two) as opposed to no response at all.

As for things like rewriting the IDE, well at least anyone that wants to has the option to do it themselves. The source for the libraries is available. The schematics are available.

The main reason I don't just incorporate things like the "free bug fix" in my personal distribution is that I am trying to keep my copy in sync (more or less) with the released one, so I can reproduce reported bugs on the forum. If I was developing something that used Strings a lot (probably not very likely) or dynamic memory, I would probably set up a second copy of the IDE and apply as many fixes as I heard about.

The frustration regarding the free bug is not so much that it can't be fixed for me -- it can -- but that I keep seeing posts on the forum like we had recently: "hey, using Strings crashes the system!"

I suppose there are many meaning to the word "fork". In the context of this "dictator or democracy" thread, I believe Wikipedia's definition is probably representative.

Wikipedia:
In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term often implies not merely a development branch, but a split in the developer community, a form of schism.

Teensyduino is absolutely NOT intended to create "a split in the developer community, a form of schism".

While much of the code I've written might be viewed as "independent development", I do have a long history of trying very hard (sometimes spending much more effort than it took to write the code) to contribute my efforts back to Arduino.

I understand there is much frustration. Believe me, I know it well.

But I want to be absolutely clear regarding my intentions, when it comes to statements such as Pico's:

pico:
Why not just fork the project to create a parallel but open and more democratic development path? Paul seems to be already doing just that in many ways with his Teensy version of the development environment anyway. In that way, the "Dicatatorship of the Stony Silence" becomes a non-issue.

I do not intend to fork Arduino, as in Wikipedia's definition above. Teensyduino is NOT intended to create a parallel but open and more democratic development path. If anything, Teensyduino is far less democratic than Arduino! It's narrowly focused on making Teensy work with the Arduino IDE, as well as I can, which sometimes involves fixing the IDE's bugs or adding minor features. Even if I do add more substantial stuff in the future, I do not intend to create a fork, in the Wikipedia definition sense, that serves as an alternate development path.