Keeping code private 'until it's ready'
by Daniel Buckmaster · in General Discussion · 07/24/2013 (5:06 pm) · 16 replies
This started as a reply to Dushan's post on Luis's recent blog, but it got a bit off-topic so I thought I'd put it here instead where we can have a bit more of a discussion on this tangential issue.
The quote that started me on this line of thought:
This post is not meant as a criticism of Dushan or anybody in particular, this was just the example that made me think about this a bit. To be honest I've been thinking about it for a while, particularly in the way the T3D Steering Committee has been operating (and possibly the T2D one, I don't know).
IMO, providing code publicly is never counterproductive. I definitely understand that it's discouraging when nobody seems interested in contributing; that sucks, and open source is all about getting everyone involved. But unless you're keeping something closed-source to commercialise it (which is totally valid, don't get me wrong), what do you lose? You should be pushing all your code to a remote server anyway, for backup purposes, so why not make it a public one?
I'm guilty myself of not pushing (or even committing) changes that completely break everything, until I can get everything unbroken. Or when I'm just messing around or something. But IMO that's different from saying 'I'll release it when it's done' or 'nobody seems to want it'. I've been working on my AI branches in public for a while now (well... I haven't pushed to them in a little while, but they're still there!). They're nowhere near finished, and some of the code is quite ugly. And I've received no interest except on my blog posts about them. Which is fine, I'm not complaining. But it's cost me nothing to have the work out there.
I mentioned the Steering Committee above - it seems like they have been working under the paradigm of releasing code only when it's complete and ready to be stuck into the main repository. To me, this seems counterproductive, especially for work that the community could help out with, provide early feedback on, or should simply have some preview of since it will involve far-ranging changes to the engine we may need to prepare for (for example, rewriting the script templates). It doesn't seem like an open development process, but a continuation of the way GarageGames is used to working on the engine (i.e. developing code in-house and releasing it as a product).
Apologies to anyone I've offended during this post. I don't mean to criticise; this is as much my way of asking a question as doing anything else. I'd love to hear some good justifications for closed-open-source (:P), I just can't deducy any myself, and the arguments I've heard haven't convinced me.
The quote that started me on this line of thought:
Quote:
For some time I thought that opening Linux repo to public was counterproductive. Let me elaborate on that, why I think like I say counterproductive. I opened Linux branch to public at that time so others can test progress so fa,r and to contribute changes if not to that repo, then to fork it and to continue with development cycle and bring one step closer to full and proper port.
But nobody (I only speak at that time) seems to care on continuing developing (most of people just want stuff, without will to contribute to development, there is also know-how factor present, I am aware of that). I base that on fact that there was several other repos what other started. I could never accept the fact that others want to lose time on rnd with them same stuff what me and Ron OHara already provided with our builds.
This post is not meant as a criticism of Dushan or anybody in particular, this was just the example that made me think about this a bit. To be honest I've been thinking about it for a while, particularly in the way the T3D Steering Committee has been operating (and possibly the T2D one, I don't know).
IMO, providing code publicly is never counterproductive. I definitely understand that it's discouraging when nobody seems interested in contributing; that sucks, and open source is all about getting everyone involved. But unless you're keeping something closed-source to commercialise it (which is totally valid, don't get me wrong), what do you lose? You should be pushing all your code to a remote server anyway, for backup purposes, so why not make it a public one?
I'm guilty myself of not pushing (or even committing) changes that completely break everything, until I can get everything unbroken. Or when I'm just messing around or something. But IMO that's different from saying 'I'll release it when it's done' or 'nobody seems to want it'. I've been working on my AI branches in public for a while now (well... I haven't pushed to them in a little while, but they're still there!). They're nowhere near finished, and some of the code is quite ugly. And I've received no interest except on my blog posts about them. Which is fine, I'm not complaining. But it's cost me nothing to have the work out there.
I mentioned the Steering Committee above - it seems like they have been working under the paradigm of releasing code only when it's complete and ready to be stuck into the main repository. To me, this seems counterproductive, especially for work that the community could help out with, provide early feedback on, or should simply have some preview of since it will involve far-ranging changes to the engine we may need to prepare for (for example, rewriting the script templates). It doesn't seem like an open development process, but a continuation of the way GarageGames is used to working on the engine (i.e. developing code in-house and releasing it as a product).
Apologies to anyone I've offended during this post. I don't mean to criticise; this is as much my way of asking a question as doing anything else. I'd love to hear some good justifications for closed-open-source (:P), I just can't deducy any myself, and the arguments I've heard haven't convinced me.
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
07/24/2013 (9:14 pm)
It was also the way we used to (had to?) work when Torque was closed-source. You couldn't just distribute your code, and it's no simple task to just whip up an SVN server and manage access control (like the community enhanced project ended up doing, with enough momentum behind it). But as good developers we should all be using version control anyway, and public options like GitHub are as convenient as any other! 
#3
OK. Let me start.
EDIT:
Counterproductive :)
We will focus our-self just on time from when Torque3D went MIT. So date is from September 20, 2012 until time of writing this - July 25, 2013, and just on features requested by people who would like to have it on T3D.
For example,
"CgFX Shader Language integration." Ron OHara's did initial support for that with linux-rnd branch. It's there for months open on GitHub, nobody as far as I know and I searched everything on forum blogs/forum posts/resources continued with development. And there is "feature request" at UserVoice and on "Intended Community Contribution" ~ "ICC" in future.
"DX11 Support." I believe that James Jones did some initial support for DirectX 11 renderer inside Torque3D and gone MIA in T3D world. Some code is there, feature request is there, nobody want to fork & continue with development.
"In game cinametics". LogicKing opened that few months.
This is just based on feature request what people would like to be included on T3D.
EDIT: I can give you list of other forks (open sourced ofc) what have awesome features, code, code examples and at end wilted like a flower.
I want to remind that whole code is released on MIT, and I am aware of fact that if you want to contribute to Torque3D you need to sign "Open Source Software Agreement".
But what is stopping me to sign agreement, fork, update code, contact original author and ask him for his permission to create pull request?
There is always possibility that somebody want to create his own work. I cannot go against that. But what's the point if there is already some initial work what you can base your work on that and possibility that somebody other learn from your experience and your examples?
Isn't that the point of open-source or I am wrong?
EDIT:
I have standing that knowledge should be shared because its hard to get it. And knowledge should be free as water and air what you breath. What's the point if only you know how something is working and others cannot learn in your experience?
like I said, I like discussion and debate :)
07/25/2013 (9:49 am)
No hard point taken from this all this. I like to think that this is new experience and I like discussion and debate.OK. Let me start.
EDIT:
Counterproductive :)
We will focus our-self just on time from when Torque3D went MIT. So date is from September 20, 2012 until time of writing this - July 25, 2013, and just on features requested by people who would like to have it on T3D.
For example,
"CgFX Shader Language integration." Ron OHara's did initial support for that with linux-rnd branch. It's there for months open on GitHub, nobody as far as I know and I searched everything on forum blogs/forum posts/resources continued with development. And there is "feature request" at UserVoice and on "Intended Community Contribution" ~ "ICC" in future.
"DX11 Support." I believe that James Jones did some initial support for DirectX 11 renderer inside Torque3D and gone MIA in T3D world. Some code is there, feature request is there, nobody want to fork & continue with development.
"In game cinametics". LogicKing opened that few months.
This is just based on feature request what people would like to be included on T3D.
EDIT: I can give you list of other forks (open sourced ofc) what have awesome features, code, code examples and at end wilted like a flower.
I want to remind that whole code is released on MIT, and I am aware of fact that if you want to contribute to Torque3D you need to sign "Open Source Software Agreement".
But what is stopping me to sign agreement, fork, update code, contact original author and ask him for his permission to create pull request?
There is always possibility that somebody want to create his own work. I cannot go against that. But what's the point if there is already some initial work what you can base your work on that and possibility that somebody other learn from your experience and your examples?
Isn't that the point of open-source or I am wrong?
EDIT:
I have standing that knowledge should be shared because its hard to get it. And knowledge should be free as water and air what you breath. What's the point if only you know how something is working and others cannot learn in your experience?
like I said, I like discussion and debate :)
#4
About the CGFx,
www.garagegames.com/community/forums/viewthread/13982
Yeah it's an old post, but think it still stands. cgFx is an nvidia solution. There are differences in how NVidia and Ati deal with certain features, swizzling is an example they used. Now it may be that since then, it's not a big deal, though it still is as they have yet to become good buddies. Nvidia and ATI do not promote compatibility with one another. If someone implements CGFx, they need to further and implement the ati alternative, etc, etc. At the very least make sure CGFx is only used on NVidia cards..
Which leads to another issue. Shader variance. Just how many specific shaders does one need to write for the game itself? Is there a way it can be compiled from the glsl for that branch in that case without intervention? Or does the solution require specific handling by the developers.
The issue with Forks and features being developed alone is a problem of the developers themselves. It's up to YOU, the developer to reach out and make a step in the right direction. If you see something someone else is doing and want to help pitch in, I would say just say so and work out the logistics of it. If they don't want to work with someone else, well their choice, but it's still up to those individual developers.
I've seen so many small sites popup and then go down it's not even funny. Though now GG provided the community involvement page, this should help. Last note, is personality type. There are some people who just will not want to work with others. I sure hope that's not true in the case for the community, but it's possible.
Does there really need to be another community development site external, to add one more resource to everything already here just so groups can mingle and go over their plans, etc?
07/25/2013 (11:16 am)
The one problem I see on that is it may take some of us a little time to get to things when we are working at a job and deving on this in free time (like me right now). It may not be a problem of no one is paying attention fast enough, it may just be no one has the time Right then. Doesn't mean it's over and done with.About the CGFx,
www.garagegames.com/community/forums/viewthread/13982
Yeah it's an old post, but think it still stands. cgFx is an nvidia solution. There are differences in how NVidia and Ati deal with certain features, swizzling is an example they used. Now it may be that since then, it's not a big deal, though it still is as they have yet to become good buddies. Nvidia and ATI do not promote compatibility with one another. If someone implements CGFx, they need to further and implement the ati alternative, etc, etc. At the very least make sure CGFx is only used on NVidia cards..
Which leads to another issue. Shader variance. Just how many specific shaders does one need to write for the game itself? Is there a way it can be compiled from the glsl for that branch in that case without intervention? Or does the solution require specific handling by the developers.
The issue with Forks and features being developed alone is a problem of the developers themselves. It's up to YOU, the developer to reach out and make a step in the right direction. If you see something someone else is doing and want to help pitch in, I would say just say so and work out the logistics of it. If they don't want to work with someone else, well their choice, but it's still up to those individual developers.
I've seen so many small sites popup and then go down it's not even funny. Though now GG provided the community involvement page, this should help. Last note, is personality type. There are some people who just will not want to work with others. I sure hope that's not true in the case for the community, but it's possible.
Does there really need to be another community development site external, to add one more resource to everything already here just so groups can mingle and go over their plans, etc?
#5
How I understand coding, you can use Cg only for the compilation of shaders, after you get the compiled code, you can use directly OpenGL/DirectX API.
My standing still remains the same (as I posted few posts up) until somebody prove me that I am wrong :)
Questions still remain, and I would like answers on them.
Thats why this is debate :)
07/25/2013 (11:57 am)
You cannot compare TGE and T3D. Not even under the miscellaneous item, and I talk like I said only on specific timeline from September 20, 2012 until time of writing this - July 25, 2013, no more, no less.How I understand coding, you can use Cg only for the compilation of shaders, after you get the compiled code, you can use directly OpenGL/DirectX API.
My standing still remains the same (as I posted few posts up) until somebody prove me that I am wrong :)
Questions still remain, and I would like answers on them.
Thats why this is debate :)
#6
It's not a matter of Cgfx implemented into TGE vs Cgfx implemented with T3D.. It's CGfx itself that's the problem. More precisely it's some of the instructions it generates that cause the issue. Just to point out, the same problem happens with Ati's solution. It doesn't work well on NVidia either.
If this can be dealt with, then it's a moot point, but last I checked, it's still a problem if not more now than when that post was written. You can't possibly expect nvidia to support ati hardware, or vice versa and that will probably never happen.
07/25/2013 (12:04 pm)
I wasn't comparing TGE to T3D, my point about CGFX Was that it's a problem on Anything that's not an NVidia card. Some instructions are ok, and some produced just aren't. The problems still range from one line in the shader not working, to an entire shader not working. That was actually my point on that. I'm not trying to point to anything else there.It's not a matter of Cgfx implemented into TGE vs Cgfx implemented with T3D.. It's CGfx itself that's the problem. More precisely it's some of the instructions it generates that cause the issue. Just to point out, the same problem happens with Ati's solution. It doesn't work well on NVidia either.
If this can be dealt with, then it's a moot point, but last I checked, it's still a problem if not more now than when that post was written. You can't possibly expect nvidia to support ati hardware, or vice versa and that will probably never happen.
Quote:But what is stopping me to sign agreement, fork, update code, contact original author and ask him for his permission to create pull request?Nothing is stopping you from reaching out to them and learning from them or even furthering their work. Hence the point that it's up to you, the developer to do so. No one is saying, don't do that. In fact, people are finally saying, please do that.
#7
And for not working on ATI/AMD card to blame their bad drivers for your system?
There are people who care only for nVidia and technologies what only nVidia is offering on market.
07/25/2013 (12:16 pm)
OK I understand you, but what is the problem if somebody would like to optimize his application only for nVidia cards, and add your game on "The Way It's meant to be played" program ?And for not working on ATI/AMD card to blame their bad drivers for your system?
There are people who care only for nVidia and technologies what only nVidia is offering on market.
#8
Yes, there sure are. That's just a choice you have to make about the market. I'm not saying there is a problem with it either.
I'm not against Cgfx, I'm just saying, NOT to 100% replace GLSL / HLSL with it. Make sure the codepath can be there and be used, but that a fallback or option is present for HLSL / GLSL. Otherwise (to me) it's just going to cause a headache (as if multiple shader languages won't).
There are people who will argue back and forth about both. Personally I don't care about either specifically. They BOTH have issues (NVidia and Ati both).
Point is, when dealing with a software that currently support both hardware, it's a bad decision to just shove the core of the system to one side of that fence only. If it's a flexible code path, then your good.. If it's inflexible, then for the core it's a problem.
It's ultimately up to you what you put into your final product. Though if the committee ultimately doesn't want to accept the patch, I still don't see an issue with that. If the committee isn't brought a patch, then it's no ones fault but the developers and community that wants the patch.
@Daniel Is it really productive to check in changes to a public repo that knowingly breaks things? That's the only thing about it (to me) and that opinion differs from dev to dev.
If it's a change someone is making and they aren't ready, and it's knowingly breaking, I don't see a reason to check it into the public repo at that point. That can just confuse newcomers to git and the whole process, but that can also be argued as to be expected. Unless it's purposefully being done for research or approval. That's currently the situation with the torquescript refactor. It's sitting there waiting for further testing, etc. Nothing is stopping anyone at this point from looking at it and making a pull request to patch an issue they find.
07/25/2013 (12:30 pm)
Quote:There are people who care only for nVidia and technologies what only nVidia is offering on market.
Yes, there sure are. That's just a choice you have to make about the market. I'm not saying there is a problem with it either.
Quote:And for not working on ATI/AMD card to blame their bad drivers for your system?That's going to happen for any card manufacturer.. Seriously.
I'm not against Cgfx, I'm just saying, NOT to 100% replace GLSL / HLSL with it. Make sure the codepath can be there and be used, but that a fallback or option is present for HLSL / GLSL. Otherwise (to me) it's just going to cause a headache (as if multiple shader languages won't).
There are people who will argue back and forth about both. Personally I don't care about either specifically. They BOTH have issues (NVidia and Ati both).
Point is, when dealing with a software that currently support both hardware, it's a bad decision to just shove the core of the system to one side of that fence only. If it's a flexible code path, then your good.. If it's inflexible, then for the core it's a problem.
It's ultimately up to you what you put into your final product. Though if the committee ultimately doesn't want to accept the patch, I still don't see an issue with that. If the committee isn't brought a patch, then it's no ones fault but the developers and community that wants the patch.
@Daniel Is it really productive to check in changes to a public repo that knowingly breaks things? That's the only thing about it (to me) and that opinion differs from dev to dev.
If it's a change someone is making and they aren't ready, and it's knowingly breaking, I don't see a reason to check it into the public repo at that point. That can just confuse newcomers to git and the whole process, but that can also be argued as to be expected. Unless it's purposefully being done for research or approval. That's currently the situation with the torquescript refactor. It's sitting there waiting for further testing, etc. Nothing is stopping anyone at this point from looking at it and making a pull request to patch an issue they find.
#9
Indeed, this is what got us stuck in DirectX-land in the first place. Slow movement on the OpenGL front apparently made someone think that it was better to drop it and go DirectX than to try to maintain compatiblity with both. Regrettable, but there it is. I think we can all agree that broadening our core compatibility is better than narrowing it....
07/25/2013 (2:38 pm)
Quote:Point is, when dealing with a software that currently support both hardware, it's a bad decision to just shove the core of the system to one side of that fence only. If it's a flexible code path, then your good.. If it's inflexible, then for the core it's a problem.
Indeed, this is what got us stuck in DirectX-land in the first place. Slow movement on the OpenGL front apparently made someone think that it was better to drop it and go DirectX than to try to maintain compatiblity with both. Regrettable, but there it is. I think we can all agree that broadening our core compatibility is better than narrowing it....
#10
But at a point, it's better to have the code 'out than in', IMO. Taking my AI work again as an example - it's likely to be 'broken' and nonfunctional for a significant amount of time. It's a lot of new stuff to add to the engine. But there is really no benefit to not allowing people to see it. Even with the code in its current unfinished state, people can still learn from it, or use it as a base for their own systems, or even finish it off if they really want it or if I decide to stop developing it.
And if I were developing this on behalf of the community, at response to a request they had made for more AI features, in some sort of official capacity, I would feel it was my responsibility to let people see the progress I was making. So they can see how the code is taking shape, whether my programming practices are appropriate, whether I'm developing features that align with what people want.
*Maybe I'm assuming too much knowledge of git when I make points like this. Using remotes, you can actually basically include someone else's repository in your own. So I could add Dushan's T3D repo as a remote on my local machine, and switch to one of his branches to try it out - and that's exactly what I'll be doing for his CMake stuff soon. And then I can make my own changes from the starting point he provides, and so on.
(EDIT: Here's me doing just that:
Now I have Dushan's code on my PC. Oh, and 'co' is an alias for 'checkout' I set up.)
And further, this means that changes don't have to go into the GG repository to be helpful. For example, if someone maintains a branch in their own repo with CGFX support, and makes sure it's always able to be merged into the latest GG development HEAD, then other people can basically use that repo as a code resource. If I'm starting a new project and I want CGFX and don't care about non-NVIDIA or whatever, I can clone GG's repo to get the base engine, add the CG repo as a remote, and pull down the CG code into my own project.
--
In other words: please share your code, unless you have a specific reason not to. That is my message. Discuss.
07/25/2013 (4:11 pm)
I'm not sure if I got my point across. What I'm arguing is that we should all be publishing our work with T3D somewhere public, unless we have particular reasons to keep it private - for example, we're working on a closed-source or for-profit application.Quote:I can give you list of other forks (open sourced ofc) what have awesome features, code, code examples and at end wilted like a flower.Definitely, there's a lot of stuff out there that's not getting much interest. I agree. It's a shame!
Quote:Isn't that the point of open-source or I am wrong?I agree, I think that is exactly the purpose of OSS development. But it all falls down if people keep their work on their own hard drives. No forking, no sharing possible.
Quote:If it's a change someone is making and they aren't ready, and it's knowingly breaking, I don't see a reason to check it into the public repo at that point.Of course, there's a limit to what you commit and push. But I'm not saying things should be added to the main GG repository. Just our own individual repositories. For example, I have branches for AI development in my own clone of T3D, which nobody ever has to see unless they go looking for it. No newbie is going to stumble across my AI work and wonder what it's doing and why it doesn't compile. But if someone notices my blog post and wants to check out my code, they can view it on GitHub, or add my repo as a remote and pull the code down themselves*.
But at a point, it's better to have the code 'out than in', IMO. Taking my AI work again as an example - it's likely to be 'broken' and nonfunctional for a significant amount of time. It's a lot of new stuff to add to the engine. But there is really no benefit to not allowing people to see it. Even with the code in its current unfinished state, people can still learn from it, or use it as a base for their own systems, or even finish it off if they really want it or if I decide to stop developing it.
And if I were developing this on behalf of the community, at response to a request they had made for more AI features, in some sort of official capacity, I would feel it was my responsibility to let people see the progress I was making. So they can see how the code is taking shape, whether my programming practices are appropriate, whether I'm developing features that align with what people want.
*Maybe I'm assuming too much knowledge of git when I make points like this. Using remotes, you can actually basically include someone else's repository in your own. So I could add Dushan's T3D repo as a remote on my local machine, and switch to one of his branches to try it out - and that's exactly what I'll be doing for his CMake stuff soon. And then I can make my own changes from the starting point he provides, and so on.
(EDIT: Here's me doing just that:
Now I have Dushan's code on my PC. Oh, and 'co' is an alias for 'checkout' I set up.)
And further, this means that changes don't have to go into the GG repository to be helpful. For example, if someone maintains a branch in their own repo with CGFX support, and makes sure it's always able to be merged into the latest GG development HEAD, then other people can basically use that repo as a code resource. If I'm starting a new project and I want CGFX and don't care about non-NVIDIA or whatever, I can clone GG's repo to get the base engine, add the CG repo as a remote, and pull down the CG code into my own project.
--
In other words: please share your code, unless you have a specific reason not to. That is my message. Discuss.
#11
For everyone else, the choice to push to a public repo, etc is their personal choice. Some may feel like doing so and receiving feedback may be counterproductive, while others are just fine with it.
There may also be some changes that we can't see until a company helping develop those changes feels ok with releasing them. It's entirely possible. There really isn't a right or wrong answer to that. Some will do it and some won't. Whether or not anyone will "buy" their reasoning is moot at that point. I'm not going to pretend that I have those answers. I'm just pointing out factors here, and unfortunately they are very real, and every project does deal with them.
To me, a project shouldn't wilt just because no one see's its source code or modifications. If the developers gave up over that, then unfortunately, I DO question their resolve on it. There are WAY too many factors at play, getting community attention, etc. You can't simply just give in.
I'm not trying to point fingers, at anyone. Nor do I mean any offense to anyone by it. I'm just simply sharing what I'm seeing.
Getting visibility to all of the changes / fixes in everyone else's repository is a bigger issue. Outside of searching the forums, that's going to be harder point to tackle, but if it was, it would help alleviate the issue with code sharing and make it a lot easier. At least to track down someone's repo up front, or to find one you didn't even know about.
Example: Linux.. The kernel is much worse about this than GG or the steering committee is and much more iron fisted. It's known, your not going to get a change into the kernel without it being accepted by them. If they don't agree, it simply doesn't go in. Is it truly "open source" if you can't influence it over a disagreement in direction?
From my perspective, what's been setup here isn't bad. It keeps code quality in check and it keeps changes in line with what they should be to become mainline. The open portion of that development model is the fact that we can all discuss or make changes, and make pull requests that impact the core. In the end, it still has to function with the changes, and the comittee is just overseeing this process making sure that the product will still function after changes are made, on top of further pushing changes / fixes as well and trying to focus efforts.
I'm not going to say people shouldn't share their code. Sure they can, and people do want to see this being done, and I'm all for it. It's one of the biggest complaints that I see on the forums. The commitee setup the community submissions tracking page and that will help address that. It won't help track everyone's projects individually that the committee didn't know was an issue, or even being developed. It's just harder to collect all of the current on going projects in one place. Addressing that problem may help address why people think their work is being ignored.
I will say this. There is evolution in the process, and still places that changes can be made, can be impactful, and could happen. Compared to closed source, that's a pretty open format. Outside of that (to me), it seems that it's more a matter of bringing up a specific issue and a proposed solution at that point. Though I do see some non constructive criticisms and critiques made in places, and that is a much worse problem than the way it's currently set up. That will actually make the project bleed members, and that's more critical than the current development model and one I'm much more worried about.
07/25/2013 (8:49 pm)
I'm glad you and others are covering what can be done with git and more importantly HOW exactly to operate it. For newcomers, anything in git may be intimidating. So it may take those people a little bit longer to come up to speed with multiple remotes. The more information available about this with examples, the more it will help those. So, Thank you!For everyone else, the choice to push to a public repo, etc is their personal choice. Some may feel like doing so and receiving feedback may be counterproductive, while others are just fine with it.
There may also be some changes that we can't see until a company helping develop those changes feels ok with releasing them. It's entirely possible. There really isn't a right or wrong answer to that. Some will do it and some won't. Whether or not anyone will "buy" their reasoning is moot at that point. I'm not going to pretend that I have those answers. I'm just pointing out factors here, and unfortunately they are very real, and every project does deal with them.
To me, a project shouldn't wilt just because no one see's its source code or modifications. If the developers gave up over that, then unfortunately, I DO question their resolve on it. There are WAY too many factors at play, getting community attention, etc. You can't simply just give in.
I'm not trying to point fingers, at anyone. Nor do I mean any offense to anyone by it. I'm just simply sharing what I'm seeing.
Getting visibility to all of the changes / fixes in everyone else's repository is a bigger issue. Outside of searching the forums, that's going to be harder point to tackle, but if it was, it would help alleviate the issue with code sharing and make it a lot easier. At least to track down someone's repo up front, or to find one you didn't even know about.
Quote:It doesn't seem like an open development process, but a continuation of the way GarageGames is used to working on the engineThis is more of a problem of what you define the development model to be. Saying Open Source is just as vague as Closed Source. That isn't a development model. It's just a format and license structure (one of many) for how the code ends up. There are no rules to how it's developed in the interim attached. The exception can be argued as closed source you can be sure that you will never get to see the code. Though it still doesn't mean you can't influence it's development. Nor is it a model of how it's being developed, in any way. Contrary to popular belief there are closed source apps that are developed in what people generally think of as an "open source" model, just without handing the code to the public. Code sharing between partners is common practice depending on the market.
(i.e. developing code in-house and releasing it as a product)
Example: Linux.. The kernel is much worse about this than GG or the steering committee is and much more iron fisted. It's known, your not going to get a change into the kernel without it being accepted by them. If they don't agree, it simply doesn't go in. Is it truly "open source" if you can't influence it over a disagreement in direction?
From my perspective, what's been setup here isn't bad. It keeps code quality in check and it keeps changes in line with what they should be to become mainline. The open portion of that development model is the fact that we can all discuss or make changes, and make pull requests that impact the core. In the end, it still has to function with the changes, and the comittee is just overseeing this process making sure that the product will still function after changes are made, on top of further pushing changes / fixes as well and trying to focus efforts.
I'm not going to say people shouldn't share their code. Sure they can, and people do want to see this being done, and I'm all for it. It's one of the biggest complaints that I see on the forums. The commitee setup the community submissions tracking page and that will help address that. It won't help track everyone's projects individually that the committee didn't know was an issue, or even being developed. It's just harder to collect all of the current on going projects in one place. Addressing that problem may help address why people think their work is being ignored.
I will say this. There is evolution in the process, and still places that changes can be made, can be impactful, and could happen. Compared to closed source, that's a pretty open format. Outside of that (to me), it seems that it's more a matter of bringing up a specific issue and a proposed solution at that point. Though I do see some non constructive criticisms and critiques made in places, and that is a much worse problem than the way it's currently set up. That will actually make the project bleed members, and that's more critical than the current development model and one I'm much more worried about.
#12
I kind of see your reasoning, but I don't think I would want to release anything that does not work properly. Maybe into a dev branch, but I am not sure what value it would have. I like to really test anything I release to make sure it will function and function properly. Maybe that is a hangup of mine in this matter. Also, I don't know that I want to jump into the Github Shell every time I make a change and dump it to a server every time I work on something.
I guess one of my changes to try and streamline the TS VM might have value. It has some bugs in it however. It is in a working state though. I was going to see if that functioned with the Script Optimizations code first.
07/25/2013 (11:02 pm)
@dB,I kind of see your reasoning, but I don't think I would want to release anything that does not work properly. Maybe into a dev branch, but I am not sure what value it would have. I like to really test anything I release to make sure it will function and function properly. Maybe that is a hangup of mine in this matter. Also, I don't know that I want to jump into the Github Shell every time I make a change and dump it to a server every time I work on something.
I guess one of my changes to try and streamline the TS VM might have value. It has some bugs in it however. It is in a working state though. I was going to see if that functioned with the Script Optimizations code first.
#13
Anyway, I'm sure I don't need to preach the benefits of source control to you!
I guess I assume throughout my arguments that people are using version control; from there it's a simple step to publishing your work. So to me, the equation looks like no cost, and unknown benefit. For others, this might look like a significant cost for unknown benefit; the equation is skewed in the other direction. Maybe what I should be arguing first is that everyone should be using source control ;P.
Once more: my arguments are mainly targeted at anyone wanting to make a significant open-source contribution, or anyone acting in an 'official' capacity with respect to Torque and GarageGames.
But of course, I think increased sharing can only benefit the engine and community, regardless of its quality or intent. I've been known to browse the GitHub 'network' graph to check out what other people are working on; it's possibly voyeuristic, but a fascinating way to see what sort of activity is going on in the community!
07/26/2013 (4:40 am)
Quote:For everyone else, the choice to push to a public repo, etc is their personal choice.Oh definitely - sorry, I do get a bit carried away. I guess my target audience with these posts is people who do intend to release their code at some point, and anyone working in any sort of official or semi-official capacity, like Steering Committee members. Beyond that, I can't and shouldn't be exhorting anybody to release their code for free.
Quote:This is more of a problem of what you define the development model to be. Saying Open Source is just as vague as Closed Source. That isn't a development model. It's just a format and license structure (one of many) for how the code ends up.Good point. When I referred to open-source, I was using the phrase incorrectly... I guess 'open development' might be a more accurate way to describe what I'm advocating. But whatever you call it, the difference remains. We can develop with a 'closed' mindset where changes are unilaterally presented to the community once they're finished in their entirety, or with an 'open' mindset which shares the code warts-and-all during development, for soliciting feedback and assistance.
Quote:Also, I don't know that I want to jump into the Github Shell every time I make a change and dump it to a server every time I work on something.Fair enough, but at some point it just becomes good programming practise to be committing all your work to version control as you do it. With git, you have the flexibility to never push that to a remote server, but IMO the benefits outweigh the disadvantages once you get used to the workflow. Seriously, there are like three commands I use daily (add, push, and checkout). And beyond the benefits of being able to access my work on different machines and having a backup, having git around means I can quickly rollback changes, perform diffs and so on.
Anyway, I'm sure I don't need to preach the benefits of source control to you!
Quote:Maybe into a dev branch, but I am not sure what value it would have.It's impossible to know! That's the thing. And by 'release' I don't necessarily mean make a song and dance and tell people and point to it. I just mean making code available. I think anyone would understand that code not in the master branch comes with no guarantees.
I guess I assume throughout my arguments that people are using version control; from there it's a simple step to publishing your work. So to me, the equation looks like no cost, and unknown benefit. For others, this might look like a significant cost for unknown benefit; the equation is skewed in the other direction. Maybe what I should be arguing first is that everyone should be using source control ;P.
Once more: my arguments are mainly targeted at anyone wanting to make a significant open-source contribution, or anyone acting in an 'official' capacity with respect to Torque and GarageGames.
But of course, I think increased sharing can only benefit the engine and community, regardless of its quality or intent. I've been known to browse the GitHub 'network' graph to check out what other people are working on; it's possibly voyeuristic, but a fascinating way to see what sort of activity is going on in the community!
#14
Not only does it allow a good programmer to look at it with a different set of eyes, but also it allows those of us with less ability to at least test and perhaps provide feedback on bugs or whatever if the subject matter is one of interest.
Take the linux work as an example, it is one of the few major mods that ive seen being worked on that i have any interest in, i will freely admit i don't have the ability to help code or fix issues, what i do have is an inordinate amount of spare time to break things. Id be quite happy to download a broken mod so long as it at least runs and help test.
07/26/2013 (4:47 am)
Isnt some of this issue why github is a good choice? a mostly broken WIP that at least compiles and runs is more than acceptable imo.Not only does it allow a good programmer to look at it with a different set of eyes, but also it allows those of us with less ability to at least test and perhaps provide feedback on bugs or whatever if the subject matter is one of interest.
Take the linux work as an example, it is one of the few major mods that ive seen being worked on that i have any interest in, i will freely admit i don't have the ability to help code or fix issues, what i do have is an inordinate amount of spare time to break things. Id be quite happy to download a broken mod so long as it at least runs and help test.
#15
I'm just thinkin some just don't have enough time to slide around that graph to find neat gems.
I just hope everyone realizes I'm not getting after anyone here for anything. I've been lengthy in responses because I've been too quiet for too long. It'll calm down, I swear.
Just providing a different perspective on this and hoping to shed light on the reality we are actually working with. There are many reasons for decisions made. Those decisions shouldn't discourage anyone. I really want to see the community get focused ;) And I'm doing what I can in my spare time to help out there.
@Bloodknight
Agreed, it is why git is a good choice. I know that some just aren't going to release until it's mostly "not broken". I'd argue to check-in for backup anyway. Though, if they don't want to we can't make them.
Demo setup a nice tool here, in this thread:
www.garagegames.com/community/blogs/view/22364/1
He was also gracious enough to put an area there for a git repos list with a summary / description for them. Hopefully that can help with pulling the information together for some of these repos that people want attention on or collaboration, etc.
Thanks Demo ;) Oh, and if we really need webspace and hosting for a site I can actually provide some on a system I've got extra here.
07/26/2013 (5:13 am)
Quote:I've been known to browse the GitHub 'network' graph to check out what other people are working on; it's possibly voyeuristicHAHA! Touche
I'm just thinkin some just don't have enough time to slide around that graph to find neat gems.
I just hope everyone realizes I'm not getting after anyone here for anything. I've been lengthy in responses because I've been too quiet for too long. It'll calm down, I swear.
Just providing a different perspective on this and hoping to shed light on the reality we are actually working with. There are many reasons for decisions made. Those decisions shouldn't discourage anyone. I really want to see the community get focused ;) And I'm doing what I can in my spare time to help out there.
@Bloodknight
Agreed, it is why git is a good choice. I know that some just aren't going to release until it's mostly "not broken". I'd argue to check-in for backup anyway. Though, if they don't want to we can't make them.
Demo setup a nice tool here, in this thread:
www.garagegames.com/community/blogs/view/22364/1
He was also gracious enough to put an area there for a git repos list with a summary / description for them. Hopefully that can help with pulling the information together for some of these repos that people want attention on or collaboration, etc.
Thanks Demo ;) Oh, and if we really need webspace and hosting for a site I can actually provide some on a system I've got extra here.
#16
@dB,
You make good arguments as to how it would benefit the community to be more open during development for projects/additions that are intended to be released. I have some pieces of code that are long overdue to be pulled into the engine, plus I have some partial code that needs other people's eyes.
I will start working with Git to get better practice of branching, tweaking, and then pushing to my fork and/or doing a pull request into the GG repo.
@smally,
Thanks for the kudos on the web resource.
07/26/2013 (1:43 pm)
Quote:Not only does it allow a good programmer to look at it with a different set of eyes, but also it allows those of us with less ability to at least test and perhaps provide feedback on bugs or whatever if the subject matter is one of interest.This is a good point.
Quote:I'm sure I don't need to preach the benefits of source control to you!Ummm...<looks side to side>...yeah...maybe you need to...
@dB,
You make good arguments as to how it would benefit the community to be more open during development for projects/additions that are intended to be released. I have some pieces of code that are long overdue to be pulled into the engine, plus I have some partial code that needs other people's eyes.
I will start working with Git to get better practice of branching, tweaking, and then pushing to my fork and/or doing a pull request into the GG repo.
@smally,
Thanks for the kudos on the web resource.
Torque Owner Edward Smith
Silencersoft
If we want to get people to work together then the code needs to be public. If you want others to help you/test code etc. Then not making it public won't help the situation.
And yes this practice should be from the top down. I know we where all disappointed when GG went from the CVS system to downloads (back in the early days).