2016-01-06 17:04 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 1/6/16 1:36 AM, Pavel Stehule wrote: > >> The CoC doesn't solve it. We do on mature, stable, pretty complex >> code - use C (not JavaScript or Java). This isn't hobby project or >> student project. >> > > No, CoC by itself doesn't grow the community. That doesn't mean we > shouldn't have one. > > Another weakness we have is the mentality that the only way to > contribute to the community is as a developer. There's tons of other > ways people could help, if we made an effort to engage them. > Infrastructure, website design, documentation, project management (ie: > CF manager), issue tracker wrangler (if we had one), advocacy. There's > probably some others. It wouldn't even take effort from the existing > community to attract those people; all we'd need to do is decide we wanted > non-developers to work on that stuff and find some volunteers to go find > them. But the big thing is, the existing community would have to welcome > that help. Part of that would mean some changes to how the community > currently operates, and the community can be very resistant to that. (I > suspect partly because it pays to be very conservative when writting > database software... :) ) >
it's true > > Taking new developers needs the hard individual work with any >> potential developer/student. I see as interesting one point - >> PostgreSQL extensibility - the less experienced developer can write >> extension, there can be interesting experimental extensions that can >> be supported without risk of unstability of core code. Can be nice to >> allow to write not only C language extensions. Then the Postgres can >> be used on universities and in some startup companies - and it can >> increase the number of active developers. My very talented colleague >> doesn't write to Postgres due C language. He like to write planner in >> lisp or erlang. Or like to play in these languages. C is barrier for >> younger people. >> > > Agreed. I recently said something to that effect to a few others, using > Python as an example. If you look at the Python source, there are 380 .c > files and 2000 .py files. Postgres has 1200 .c, 2000 .h and only 652 > .sql. Since there's 640 .out files most of the .sql is presumably tests. > I'm not suggesting we switch to Python; the point is we could do a > better job of "eating our own dog food". I think it would also be very > interesting if there were add-on frameworks that allowed things like a > planner written in another language (which with the planner hooks might > actually be possible). > > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com >
