call for leaders

you might have noticed that the openFrameworks community is full of a massive amount of energy and potential. we want to make sure none of this goes to waste, and that everyone feels their contributions are important. to help accomplish this, i’m taking on the new role of ‘community advocate’.

this means i’ll be finding ways to channel all the energy from the OF community: making sure contributions and suggestions go to the right places, and that the right people get connected with each other.

because OF is too big for one person to oversee, we want to find some people to take responsibility for smaller chunks. a few people have already self-selected by making massive contributions, and we’re excited to continue supporting them in these roles:

  • addon leaders: the crew, including james and greg
  • github leader: cristoph (bilderbuchi) who has done massive work on issues and milestones

we’re looking for a bunch more leaders. the responsibilities and powers will vary, but the general idea is to find people who are knowledgable and excited to contribute. “contribute” might mean: answering questions on the forum, making design suggestions, squashing bugs, writing documentation, or adding features. here are some positions and directions we have in mind

  • 3d leader: GL, ofCamera integration, 3d i/o, shader examples
  • 2d leader: introducing vector file i/o
  • sound leader: working on a new sound chain for OF and synth/DSP
  • typography leader: better type formatting, control and display
  • hardware leader: serial, arduino/firmata
  • video leader: this is a very cross-platform problem, but we’re interested in gstreamer
  • iOS leader
  • internals leader: windowing, threads and events
  • tutorial leader: we want to make a user-contributed tutorial wiki, moving away from the current wiki. this is a huge project and requires more discussion.

if there’s a smaller piece you want to bite off, or something you want to work on that isn’t listed here, let us know. again: my job is to take whatever energy you have, and figure out how to make the most out of it!

contributions to the core will remain the same: contributors work in their own fork, and one of the core members will merge their pull request. in the past, this has sometimes meant that pull requests sit around for a while before getting merged or rejected. we’re trying to avoid that situation by making sure developers have clear expectations of what is needed, and how it should be designed.

writing the ‘design philosophy’ (on the new ‘about’-page) is a first step in this direction. the ‘code-style’-guidelines (on github) are also working in this direction. finally, cristoph has a number of issues tagged ‘development-strategy’ on github that need to be discussed in order to guide OF towards a more consistent future.

if you’re interested in one of these positions, post in this thread. we’ll try and sort out all the people who are interested. as we pick people we’ll post here with the announcement and a description of what to expect. positions will last for half a year, at which point we’ll do a recap and pick new (or the same) people.

Great idea, I agree that a person tying all this together, coordinating efforts, is really useful.
I hereby affirm my self-selection as github/issue-maintenance guy. ;D

With regard to code contributions, if anyone has questions about git, github, and how to effectively contribute code to OF using the “official” workflow, read OF-git-workflow.


I’d love to be hardware Guy :slight_smile:

Hello! I’m really into tutorials… I have some of them written on Spanish ( ) I would love to add them to a wiki and contribute opening the community for spanish-speakers.
Also I’m interested on GLSL shaders examples ( )

id be keen to get more involved on the iOS side of OF! :slight_smile:

Super happy to work on the typography stuff/push this forward. I have a real good grasp on the inner workings of ofFreetype and have already done a bit of a rewrite that I’d love to complete and add some awesome functionality to!

I’d be happy to work on the internal structure of openframeworks. I could start by contributing to the windowing topic. Because of my work on ofxFenster, I’d love to have better (multiple) window handling built into of. Maybe even officially move away from GLUT in an upcoming release.

But I’ll soon be away for six weeks. so if anybody is eager to get something done before that. go ahead and don’t wait up.

I’m down/up for 3D.

I think my biggest weakness is with the line of the Design Philosophy:

openFrameworks is consistent and intuitive: it should operate on the principle of least surprise, so that what you learn about one part of openFrameworks can be applied to other parts of it.

I think this is quite relevant to previous debates of “2D is like this, but lets do 3D this way instead because it’ll be more intuitive / powerful / cleaner in the long term”.

My general principle would be “apply general oF approach, syntax, classes, structs, etc to 3D, but avoid forcing a continuity between 2D and 3D where its dubious, however add continuity/helpers where not”.

As long as I can tread that line well then I hope to serve the community. swear me in! (as long as everyone else better’s busy!)


I’d be really happy to be the video guy!
I’ve had to deal a lot with the cross-platform problems of it.

@roy - video currently seems to be the key to 64bit, i.e. apart from getting 64bit video working on all platforms, i’m not sure there are any major challenges to 64bit compilation on windows/osx in the oF core

64bit would be awesome. would love it if this became a priority!
(awesome for >2GB ram access, awesome to not spend time recompiling libs to 32bit on a 64bit machine)

yes 64bit would be great.
An included and reliable alpha video playback would be great.
One thing i’ve found that’s really annoying is that when a new videos begins playback a blank frame is displayed.
I’ll dive into OF’s core and see what I can get.

hey all

i’d be happy to take on the sound lead role. i’ve been hacking around on the sound portion of openFrameworks in order to use it on embedded devices (pandaboard/beagleboard) so i know most of the ins and outs of sound programming – at least, enough to make something that is useful for others to use!



I’d love to keep the momentum up on this incentive

I find that the chasm between having an idea / requirement for something to being in the core, and it finally getting there is large (too large for me at least!).

I’d say that adding an individual function can take 2-8 hours distributed over 1 to 2 weeks(obviously the actual development time isn’t generally a big portion of this). Giving up along the way can lead to having to rewrite the function because the core has changed too much in the meantime (though this is generally only true at the time of a bigger release).

My ‘solution’ is to split up the addition of new functionality into 3 stages.

  1. Add function to ofxCore3d (a ‘testing ground’ add-on which is trivial to work with / add functionality to/ got around with. Filenames mirror the core filenames, e.g. ‘of3dUtils-extend.h’). I see this as much easier for lots of developers to work on for more casual hacking. Pull requests would almost always be accepted.
  2. Functionality from ofxCore3d then gets moved into a feature branch of the core by whoever’s heading up the 3d dev (me first!).
  3. pull request for openFrameworks gauntlet core approval process. At this point lots of things can be reviewed at once

The idea is that by the time you get to step 2, you’ve sorted out formatting, had a chance to test it out properly, and people can use the functionality in the mean time.

I think this would save time during development of new features (hacking on the core is much messier than hacking in an addon)
It would save time on pull requests (make lots of / review lots of changes at once with one person in charge of consistency for each oF subsection).

There’s some bits that would need a little extra time
E.g. If you change the definition of a core function / core class
I’ve got some ideas how to get around this

Reactions most welcome. I personally dont believe tha working on a git branch at step 1 is the way to go.
Gotha run,

I agree with you that the integration workflow must be streamlined and made more efficient/immediate. Currently we have 17 pull requests waiting for integration, some have been opened upwards of half a year ago, and have yet to receive any comments/feedback by the integrators (i.e. arturo, theo, zach), so I can understand your frustration.

In my opinion, though, instead of inserting intermediate steps for integration, it would be preferable to have a better policy for pull requests.
Pull requests should not lie uncommented for a long time. The integrators should give feedback to the submitter as to what the PR needs (e.g. testing, code style), what should be improved, or why it won’t be merged,… so that the submitter has opportunity to work on this, and amend the PR in due time.
As of now, we have 9 PRs which never received a single comment. This silence can’t be encouraging for contributors to OF.

As to your points, elliot, I’d like to elaborate why I don’t agree:
ad 1) I don’t know how manageable it will be to add features/bug fixes to the core (which will often necessarily have to modify existing core code) in an extra addon. I don’t see how that should work out without a major headache, and I don’t think it will make the process easier.
What do you mean by “PRs will almost always be accepted”, and what will be the difference to PRs directly against the core? better integration policy/discipline for the addon?
ad 2) Don’t you think that moving stuff into a feature branch, after having it in the addon, will be prone to introduce/uncover other bugs/errors?
ad 3) I think having to review lots of things at once (i.e. pooling many features/bug fixes into one PR) will not improve the process, but make it worse: discussion in the PR will have to encompass many issues (and will therefore be more confusing), questions on one issue block the integration of already cleared code (due to being lumped together in one PR), granularity is lost, effort of code review rises sharply due to more code, and more complicated testing to isolate potential problems.

yes, by the time you get to step 2, formatting and testing will be done already, but will have to be done again since the code moves to another location.

Also, could you elaborate on why you think it’s easier to hack on an addon than in a core branch? Both are just a couple git commands away (2 at most I think - git remote add other-repo && git pull other-repo/branchname, for a core branch), and if you contribute code, you should know some git anyway. OTOH, you have to know (significantly, I think) more C++ to seamlessly integrate what you write into the core, when it’s in fact residing in an addon.

All in all, though, I think our integration workflow has to be improved to keep contributions coming, and I thank you for bringing it up, I was on the verge of doing so myself. :slight_smile:

The most obtuse things I find with the current system are:

1. It’s disruptive to workflow
As you develop your own project, you add a feature (presume core). The long term stability of your project now relies on this feature getting pulled.

Ok, so best get a pull request into good shape (move changes into a branch of latest develop, which is a little messy / risky if you’ve got any other changes, which is pretty common). Since you’ve now pulled latest develop and got your feature into a named branch and a pull request with it’s name on it, the main project you started with now likely doesn’t work

I’d say that despite best intentions otherwise, a considerable amount of times when you move up, something will break. Now since your project’s broke, you spend time fixing that (and it should really be tested against latest develop). The whole point you started this in the first place is that you’re making something to enable your project, right? Chances are you can fix it, but spending this time is still a distraction, sometimes it’ll kill the rest of your day. All that magic you had in your head is now cleaned out.

in the end the pull request is commonly ignored or pinged back. Your work is now in limbo and in serious danger of being lost forever.

I’d say that’s my most common experience. Within that there’s also lots of other small steps in the process that take time. This may sound over the top. I’ve had better scenarios.

2. The issue of limbo
I touched on this above. A rejected / ignored pull request is a burden for the contributor.

They have to go through the above process again if they want to retry a pull request, or have to reformat their code into an addon or something else that they can apply to their projects that need it (perhaps a git branch!)

my belief is that pull first, reformat later simply works better.
Having a connection to the thing that your pulling against is much more satisfying for the contributor
And is much less effort for the contributor (including coming back to make the necessary changes).
That’s never going to happen in the core

Generally I’m going to allow almost all pull requests, and then periodically move selected functionality into a core pull request (whilst moving to core, I can ensure proper oF conventions and tie in with examples). Some functionality would otherwise get moved out into separate addons.

The other option (to having an extension testing ground) is of course to have a branch testing ground. The 2 disadvantages to this are:

  1. It’s difficult to keep track of the contents (you have to look at the git history against the files, instead of just the files themselves). An example of where you might want to do that is when the section leader needs to check everything is in good shape before requesting a pull into the core.
  2. Anybody who wants to use the features, has to checkout that branch which messes with their core.
    I presume this is the de-facto option for this thread (branch the core for section)
    This still has the granularity issue when pulling into develop (bilderbichi mentioned above)
    I believe that issue is dealt with by the section leader as each feature is introduced. In which case this is the same for both working in an addon or a branch

Git is, well… Not perfect, right?
I mean, nothings perfect. And git certainly fits that rule
The question is how much it accomodates for itself being imperfect
At best its a wonderful way of dealing with code, at worst it’s the OCD nightmare of “git doesn’t have that function because you’re not supposed to work that way”

Gotta run again…

Hm, could you elaborate on which functions you miss in git, preventing you from working in a certain way? maybe I can shed some light.

As to the breaking project scenario you raise in your first point, I’ll try to show how I would do it:
let’s say you work in the develop branch, hacking on a project of yours (let’s call it project x).
in the course of this, you add some features to the core which you need for this project. those are teased out and put in branch feature-a for a nice PR against develop.
then all you need to do is

git checkout develop (if you're not already there)  
git checkout -b project-x  
git merge feature-a  

to get a well-formed pull request for upstream, and an unchanged codebase for your project.
furthermore, say you also have some more features you need for your project, and those are also in their own branches. then you just have to

git merge another-feature  
git merge yet-another-feature  

to include these in you project branch. now you just have to wait until those PRs get merged in to be able to switch back to develop. if there are updates in the meantime, it’s easy to merge them from develop into project-x.
Is this clear and understandable, or not? I think I’ll look at the wiki again and see if I can improve/elaborate the git workflow guide there to present more use cases.

hey bilderbuchi!
of course. this is what i’d expect. thanks for putting it clearly
thanks x

back to before…
I know that ofx3dAdditions would be messy in situations where you need to change definitions, but still cleaner when you want to add new symbols.

the solution (for me) is probably going to be somewhere between a 3dAdditions branch and a separate repo.

I guess i can start right now with:
0. use a core branch ‘3dAdditions’

  1. dont actively try to keep the 3dAdditions branch at develop (anybody can merge it into their local develop if they wanted).
  2. don’t create a branch per feature (unless it’s not related to 3d. in which case make a seperate branch and pull request against that section leader)
  3. accept pull requests from others (i generally wouldn’t expect branch per feature, and expect in some cases i would be the person to merge files manually)
  4. pull request the branch into core develop periodically (and in advance sort code out for compatibility and consistency*)

i’d introduce the separate repo if that wasn’t smooth enough

* for this step, it’d be great to get some kind of git report i could print out with all the changes listed. is there a git command to show all code changes (with filenames and actual code) since a commit hash? An easy way would be a pull request into core develop (perhaps with a ‘please wait’ comment), then just print/pdf the github page.

i suggest a pull request week (perhaps every 2 months) where all the sections pull in the changes they’ve had, and the core team looks through them. Perhaps we stagger so that they don’t all come in at once (if that indeed does cause any advantage, since whoever’s last could have more changes to make). Anyway, we would need a time where theo/arturo/zach are definitely available to manage the pull requests.

it would be great to get some confirmation from kyle about when to ‘start’.
i mean something like “ok, so you’re section leader for 3d until July, or until you bring down the github account (whichever comes first)”

edit: I split out some subsequent git discussion to a separate topic:

[quote=“elliotwoods, post:17, topic:8391”]
it would be great to get some confirmation from kyle about when to ‘start’.
i mean something like “ok, so you’re section leader for 3d until July, or until you bring down the github account (whichever comes first)”[/quote]
I think there won’t be an initiation ceremony. :wink: I understood the call as “effective as soon as you raise your hand”.

i want to start with an apology – the first post in this thread is from a month ago. i’ve been doing a lot, from my usual work, to bigger projects, to moving apartments… and i didn’t have the time i was expecting. i’m about to start teaching a class at ITP this week, but the OF community is super important to me. so i’m going to try and keep up to date with the forum even if i can’t respond to as many threads. if you ever have an immediate question please feel free to email or direct message me :slight_smile:

so! i’m very happy to announce the confirmed section leaders:

  • 3d leader: Elliot Woods (elliotwoods)
  • 2d leader: none
  • sound leader: Damian Stewart (damian)
  • typography leader: Steve Varga (stevevarga)
  • hardware leader: Josh Noble (joshua noble)
  • video leader: James George (obviousjim)
  • iOS leader: Lukasz Karluk (julapy)
  • internals/app leader: Philip Whitfield (underdoeg)
  • tutorial leader(s): Diederick Huijbers and Jeff Crouse (roxlu, jefftimesten)

the idea is that these positions will last until july, then they’ll automatically end, and we’ll ask again. we don’t want anyone to feel locked in, but we want to provide a long enough period of time that people can get something done.

i’ve already emailed a few of you separately to talk about this stuff, but there’s more to respond to in this thread as well.


apply general oF approach, syntax, classes, structs, etc to 3D, but avoid forcing a continuity between 2D and 3D where its dubious, however add continuity/helpers where not

this generally sounds right to me. there’s definitely a line to tread. for example, OF’s coordinate system is nonstandard compared to GL (bottom left), but standard compared to Processing, FreeImage, and a few others (top left). when it gets to specifics, i think “intuitive” will triumph as the default, but “counter-intuitive yet more powerful or standardized in other ways” should always be an option. if you can think of a better way to reflect this in the design philosophy, that would be great.

My ‘solution’ is to split up the addition of new functionality into 3 stages.

super interesting proposal, but i just recently asked ZAT about something like this for examples, and they didn’t like the idea.

i think a more powerful solution will be to drop step 1, so when people want to submit a feature they work in the “section-3d” branch (for example) which they can submit a pull request for. you can manage the section-3d branch, and merge to/from it as you desire, and that will act as the staging ground for moving into develop (the core will move things into develop).

i think this also solve’s cristoph’s issues about pull requests going uncommented. if you’re always committing to a feature branch, then the feature leader can comment.

I think having to review lots of things at once (i.e. pooling many features/bug fixes into one PR) will not improve the process, but make it worse

if there is a lot of discussion around pull requests from the “section” branches into develop, then that means i’m not doing a good job communicating what the core expects, or the section leaders have been ignoring those expectations and pulling things anyway. things should flow pretty seamlessly if we’re in agreement about where OF is going.

i also think the feeling from the core (especially arturo) is that leaders should not be spending most of their time significantly restructuring their sections, or implementing tons of new features. it should mostly be about bug fixes, compatibility fixes, optimizations, and clarification.

As you develop your own project, you add a feature (presume core). The long term stability of your project now relies on this feature getting pulled.

i think not everyone should expect that all their changes to the core will be pull. but the section leaders should understand what is supposed to be in the core, and what isn’t. and if they can add something that should be in the core, then it will go in. if it doesn’t belong in the core, it should be in an addon anyway.

in other words, i’d like to hope that by creating these section leader positions we have better communication between what is expected and what is developed, and therefore have far fewer problems with unmerged code.

As to the breaking project scenario you raise in your first point, I’ll try to show how I would do it:

bilderbuchi, you make a lot of sense in this post.


i think this is what the workflow has to look like for (contributors -> leaders -> core).

  1. the core creates branches for each section, called “section-*”, e.g., section-3d, section-video, section-type, etc.
  2. section leaders are given admin access on the OF repo with the understanding that they should only manage their respective branch
  3. contributors issue pull requests to the respective section branches, or just “develop” if it doesn’t fall under any section
  4. the core (probably just arturo) reviews the section branches periodically and merges in to develop
  5. the core (plus the community) collectively decides, using milestones etc., when develop is ready for master, and we do a release.

i’ll try to get some comments from ZAT on this.

i’m still talking to the core members about whether this is a viable direction, but i’d love to hear more comments in the meantime (especially on the last section).