[OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot <mateusz@loskot.net> wrote:
Hi, I will only refer to complain on the slow SOCI release schedule. So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it.
I'm not sure but is CppDB a fork of SOCI? If that was the case, then the original copyright holders of the original code would have to be consulted if the fork was going to be released under a different license. IANAL, but there may be some issues with forking a BSL-licensed project to be an LGPL project.
This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about software here makes me asking, what's next? Boost libraries forked?
Well... actually... forks are a valid means of diversification in FOSS projects. Whether it's successful in what the fork is supposed to achieve is a different issue altogether. About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained". The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;)
Anyways, I'm just disappointed how much FOSS is ego-driven where it should mean collaboration. Just pity.
+1 in general. -- Dean Michael Berris deanberris.com
On 15/12/10 02:20, Dean Michael Berris wrote:
On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot<mateusz@loskot.net> wrote:
Hi, I will only refer to complain on the slow SOCI release schedule. So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it.
I'm not sure but is CppDB a fork of SOCI?
It is not a direct fork of code. I believe I explained it in my reply to Artyom's post.
This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about software here makes me asking, what's next? Boost libraries forked?
Well... actually... forks are a valid means of diversification in FOSS projects.
Technically and formally valid, but not necessarily valid in terms of sustainability. Thinking in terms of r/K selection theory, which one would be better for FOSS (assuming no funds).
About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained".
Forking never solves maintenance problems, but introduces new ones.
The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;)
Forking projects is not the same as forking in Git (like at github). Forking a project is similar to this story: Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks. let's leave it and make new Rome v2 in south-west. I joined this thread because I could not understand the sociological aspect of this decision. Perhaps it's me and nowadays more folks consider it easier to quit a job than to work out a compromise :-) I honestly wish Artyom good luck. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On Wed, Dec 15, 2010 at 7:45 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 15/12/10 02:20, Dean Michael Berris wrote:
On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot<mateusz@loskot.net> wrote:
Hi, I will only refer to complain on the slow SOCI release schedule. So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it.
I'm not sure but is CppDB a fork of SOCI?
It is not a direct fork of code. I believe I explained it in my reply to Artyom's post.
Yep, read that too. I just wanted to check if my understanding of "fork" was correct.
This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about software here makes me asking, what's next? Boost libraries forked?
Well... actually... forks are a valid means of diversification in FOSS projects.
Technically and formally valid, but not necessarily valid in terms of sustainability. Thinking in terms of r/K selection theory, which one would be better for FOSS (assuming no funds).
Here's the thing though, if the fork succeeds, it eventually becomes the "main" project. This has already happened with MariaDB and MySQL, Firefox and Mozilla, X11 and X.org, etc. -- there's no "sacredness of the root" when it comes to FOSS, and I think that's a good thing. This means, if the original project wasn't going according to a number of contributor's (or community members') liking, then forking is always an option. The reason most forks exist is that the original approach is not sustainable. Sustainability in the sense that original design/process decisions were deemed wrong by some people and that they think it's better to either do it over or gut the software/project and bring it to a new direction than trying to fix the original. This is where the concept of a non-sacred source makes sense -- think how CMUCL got forked into many various CL implementations and how each one has thrived. Also, sometimes, having just one project isn't also sustainable -- which is why forks make sense for a means of diversification and innovation. ;)
About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained".
Forking never solves maintenance problems, but introduces new ones.
Not really. The fact that something is unmaintained and that people other than the original maintainers want to maintain a fork of it, I don't see how it introduces a new maintenance problem. The fork might be more actively maintained by the people that forked the original project, or the new project allows more contributors to get involved, or offers a better means of iterating/innovating than the original project... in that situation the non-maintenance project is actually solved by allowing others to maintain it outside the original project.
The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;)
Forking projects is not the same as forking in Git (like at github).
Eh?
Forking a project is similar to this story: Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks. let's leave it and make new Rome v2 in south-west.
That's a re-write, not a fork. A fork would be: Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks; who's with me, I'm going to bring the good parts of Rome and build a city that's in the south-west but this time with dedicated cleaners, hospitals, proper waste management facilities, and cool new sights.
I joined this thread because I could not understand the sociological aspect of this decision. Perhaps it's me and nowadays more folks consider it easier to quit a job than to work out a compromise :-) I honestly wish Artyom good luck.
Well, these days I think at least compromises seem to be overrated. If you can't get to Win/Win, there's always No Deal. ;) -- Dean Michael Berris deanberris.com
Dean Michael Berris wrote:
On Wed, Dec 15, 2010 at 7:45 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 15/12/10 02:20, Dean Michael Berris wrote:
On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot<mateusz@loskot.net> wrote:
This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about software here makes me asking, what's next? Boost libraries forked?
Well... actually... forks are a valid means of diversification in FOSS projects.
Technically and formally valid, but not necessarily valid in terms of sustainability. Thinking in terms of r/K selection theory, which one would be better for FOSS (assuming no funds).
Here's the thing though, if the fork succeeds, it eventually becomes the "main" project. This has already happened with MariaDB and MySQL, Firefox and Mozilla, X11 and X.org, etc.
Firefox is not a fork, but the same team and the same organization decided to change their strategy from the Mozilla Suite to two separate products. X.org is a fork and successful indeed. MariaDB was as necessary answer to MySQL closed for community-driven development. Though, I haven't seen a lot of critical mass around MariaDB. Dean Michael Berris wrote:
About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained".
Forking never solves maintenance problems, but introduces new ones.
Not really. The fact that something is unmaintained and that people other than the original maintainers want to maintain a fork of it, I don't see how it introduces a new maintenance problem.
There are plenty of new problems. Forking is not about copying, changing and throwing out on the public server. In many cases it meets same problems as any other startup project. Dean Michael Berris wrote:
The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;)
Forking projects is not the same as forking in Git (like at github).
Eh?
Yes, it's not just copying a code, as long as we both understand a project is not only a source code. Code is an extremely important part of a project, but it's not critical part. As every piece of software is useless without data, any forked source code is dead without community which uses and maintains it.
Forking a project is similar to this story: Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks. let's leave it and make new Rome v2 in south-west.
Dean Michael Berris wrote:
That's a re-write, not a fork. A fork would be:
Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks; who's with me, I'm going to bring the good parts of Rome and build a city that's in the south-west but this time with dedicated cleaners, hospitals, proper waste management facilities, and cool new sights.
I've assumed the "bringin the good parts". I should have made it clear. Dean Michael Berris wrote:
I joined this thread because I could not understand the sociological aspect of this decision. Perhaps it's me and nowadays more folks consider it easier to quit a job than to work out a compromise :-) I honestly wish Artyom good luck.
Well, these days I think at least compromises seem to be overrated. If you can't get to Win/Win, there's always No Deal. ;)
I don't think compromises are overrated. My general point is that it's easy to fork (as it's easy to create new FOSS project), but following steps are very difficult to make it success. What I have observed here, is what I'd call "premature forking" and that's why I don't understand such decisions. Here is article that precisely explains my concerns, especially: When to fork? When you have exhausted all other options. http://fossfaq.com/questions/52/what-does-it-mean-to-fork-an-open-source-pro... I have not seen such exhaustion. Best regards, ----- -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- View this message in context: http://boost.2283326.n4.nabble.com/OT-Open-Source-Forking-and-Boost-was-Re-S... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, Dec 15, 2010 at 8:54 PM, mloskot <mateusz@loskot.net> wrote:
Dean Michael Berris wrote:
Here's the thing though, if the fork succeeds, it eventually becomes the "main" project. This has already happened with MariaDB and MySQL, Firefox and Mozilla, X11 and X.org, etc.
Firefox is not a fork, but the same team and the same organization decided to change their strategy from the Mozilla Suite to two separate products.
Which is by definition, a fork.
X.org is a fork and successful indeed. MariaDB was as necessary answer to MySQL closed for community-driven development.
And is a fork -- everybody could have continued with contributing to MySQL and assigning rights to Sun (now Oracle), and most of the (public) innovation is happening on the MariaDB side.
Though, I haven't seen a lot of critical mass around MariaDB.
Yet. ;)
Dean Michael Berris wrote:
The fact that something is unmaintained and that people other than the original maintainers want to maintain a fork of it, I don't see how it introduces a new maintenance problem.
There are plenty of new problems. Forking is not about copying, changing and throwing out on the public server.
Eh? That's the simplest definition of a fork. Unless I'm missing what you mean by fork.
In many cases it meets same problems as any other startup project.
Sure, but the maintenance problem that was there is solved by the new project because the new one is maintained at the time of the fork.
Dean Michael Berris wrote:
The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;)
Forking projects is not the same as forking in Git (like at github).
Eh?
Yes, it's not just copying a code, as long as we both understand a project is not only a source code. Code is an extremely important part of a project, but it's not critical part. As every piece of software is useless without data, any forked source code is dead without community which uses and maintains it.
So, what else is there aside from code/documentation in an open source software project? Community of users and developers -- well, if it's a fork, you can build that community on your own or potentially get people from the original project. Support fora -- well, you can (easily) create mailing lists now and even online web forums to provide community support. Funding -- well, it's the same issue that any other open source project faces anyway, I don't see why a fork would be especially harder to fund than any other project. With forks, you'd have that "scratch your own itch" and "build it and they will come" mantra's. Unless you do both, you're not going to get far, and this applies to any open source software project.
Forking a project is similar to this story: Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks. let's leave it and make new Rome v2 in south-west.
Dean Michael Berris wrote:
That's a re-write, not a fork. A fork would be:
Caesar of Rome says: this city stinks, is dirty, unhealthy, it sucks; who's with me, I'm going to bring the good parts of Rome and build a city that's in the south-west but this time with dedicated cleaners, hospitals, proper waste management facilities, and cool new sights.
I've assumed the "bringin the good parts". I should have made it clear.
See, the other part you missed is the question "who's with me?". Anybody can fork any open source project, that's a given -- but then getting critical mass behind you to be successful is something else. Now, let's say you are charismatic and can get people behind you to leave the original project behind and take the fork to a different direction, then I don't know what the problem with forking is -- aside from, well, potentially killing the original project, which sometimes, is a good thing.
Dean Michael Berris wrote:
I joined this thread because I could not understand the sociological aspect of this decision. Perhaps it's me and nowadays more folks consider it easier to quit a job than to work out a compromise :-) I honestly wish Artyom good luck.
Well, these days I think at least compromises seem to be overrated. If you can't get to Win/Win, there's always No Deal. ;)
I don't think compromises are overrated.
Hehe, to each his own then. ;)
My general point is that it's easy to fork (as it's easy to create new FOSS project), but following steps are very difficult to make it success. What I have observed here, is what I'd call "premature forking" and that's why I don't understand such decisions.
Okay, but making something successful involves work -- regardless of whether it's the fork or the original project. So I don't see why forking should be discouraged even if there is no good reason to do it aside from "well, because I can and I want to".
Here is article that precisely explains my concerns, especially:
When to fork? When you have exhausted all other options.
http://fossfaq.com/questions/52/what-does-it-mean-to-fork-an-open-source-pro...
I have not seen such exhaustion.
I actually disagree with that answer. You fork when: - You want to. It should be that simple really. ;)
Best regards,
HTH By the way, my assertion is that forking, in general, isn't a bad thing; that diversification should be encouraged especially if it will bring innovation and covering new ground. The consolidation can happen later on when the good ideas can start cross-pollinating across the diverse tracks, and improve the overall state of the art. I am by no means willing or even remotely considering forking Boost libraries -- especially since I cannot maintain any new Boost libraries other than the one I intend to submit for review and develop on my own. However I don't see why anybody who has the wherewithal or the motivation to actually either take over some of the Boost libraries in a fork -- heck, or the whole Boost project for that matter -- should be discouraged from doing so. This might just be me though. ;) -- Dean Michael Berris deanberris.com
On 15/12/10 13:42, Dean Michael Berris wrote:
On Wed, Dec 15, 2010 at 8:54 PM, mloskot<mateusz@loskot.net> wrote:
Dean Michael Berris wrote:
Here's the thing though, if the fork succeeds, it eventually becomes the "main" project. This has already happened with MariaDB and MySQL, Firefox and Mozilla, X11 and X.org, etc.
Firefox is not a fork, but the same team and the same organization decided to change their strategy from the Mozilla Suite to two separate products.
Which is by definition, a fork.
Technically, yes but organizationally no. The same organization, the same people. I'll remind, I'm considering a project as the whole machine producing a code. A project is not only a code.
The fact that something is unmaintained and that people other than the original maintainers want to maintain a fork of it, I don't see how it introduces a new maintenance problem.
There are plenty of new problems. Forking is not about copying, changing and throwing out on the public server.
Eh? That's the simplest definition of a fork. Unless I'm missing what you mean by fork.
I've tried to explain it at least two times.
The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;)
Forking projects is not the same as forking in Git (like at github).
Eh?
Yes, it's not just copying a code, as long as we both understand a project is not only a source code. Code is an extremely important part of a project, but it's not critical part. As every piece of software is useless without data, any forked source code is dead without community which uses and maintains it.
So, what else is there aside from code/documentation in an open source software project?
Community of users and developers -- well, if it's a fork, you can build that community on your own or potentially get people from the original project.
You can or you can not. There are plenty of reasons why users and developers won't drift with forks.
Support fora -- well, you can (easily) create mailing lists now and even online web forums to provide community support.
Technically, it's easy. Next, you have to have time to maintain the traffic, answer questions, provide support. When you have 100 folks subscribed, it's easy to spend 2 hours a day on it.
My general point is that it's easy to fork (as it's easy to create new FOSS project), but following steps are very difficult to make it success. What I have observed here, is what I'd call "premature forking" and that's why I don't understand such decisions.
Okay, but making something successful involves work -- regardless of whether it's the fork or the original project. So I don't see why forking should be discouraged even if there is no good reason to do it aside from "well, because I can and I want to".
You still don't understand my point. I'm not trying to discourage forking. I'm not suggesting forks are evil. I'm commenting very specific situation which has emerged and the reasons which are unclear to me.
Here is article that precisely explains my concerns, especially:
When to fork? When you have exhausted all other options.
http://fossfaq.com/questions/52/what-does-it-mean-to-fork-an-open-source-pro...
I have not seen such exhaustion.
I actually disagree with that answer.
You fork when:
- You want to.
It should be that simple really. ;)
We all are free as wild pigs and we can do whatever we wish. I'm trying to stay with frames of reasonable thinking and strategic planning, with some principles of business. If there is no pragmatism and rationale behind your decision but "want to" then it's ego-driven development.
HTH
By the way, my assertion is that forking, in general, isn't a bad thing; that diversification should be encouraged especially if it will bring innovation and covering new ground. The consolidation can happen later on when the good ideas can start cross-pollinating across the diverse tracks, and improve the overall state of the art.
I am by no means willing or even remotely considering forking Boost libraries -- especially since I cannot maintain any new Boost libraries other than the one I intend to submit for review and develop on my own. However I don't see why anybody who has the wherewithal or the motivation to actually either take over some of the Boost libraries in a fork -- heck, or the whole Boost project for that matter -- should be discouraged from doing so.
I agree with this, actually, but it's slightly far from the point of this specific situation I've tried to ask about and understand. If someone says "I don't want to do it, to maintain new piece of software myself, but I have no choice" but there is no track of discussion that would lead to such conclusions, then I'm far from understanding such what's the real reason. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On Wed, Dec 15, 2010 at 7:14 AM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 15/12/10 13:42, Dean Michael Berris wrote: ... You fork when:
- You want to.
It should be that simple really. ;)
Turns out, it is (with a sufficiently permissive license). ;-)
We all are free as wild pigs and we can do whatever we wish. I'm trying to stay with frames of reasonable thinking and strategic planning, with some principles of business.
That's great! But not all of us are in "this" with the same interests, goals, or even the same concept of "reasonable" thinking.
If there is no pragmatism and rationale behind your decision but "want to" then it's ego-driven development.
If there is no rationale, then it sounds like a whim to me. If there is no pragmatism, it's probably doomed. So what? I still say go for it, if that's what you want. You're probably not getting paid for it in any case, so it better ultimately be what you want. ;-) Jon
On Tue, Dec 14, 2010 at 9:20 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained"
I'd much rather see maintenership of these libraries transferred to new people, just to avoid fragmentation. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Dec 16, 2010 at 2:33 AM, Dave Abrahams <dave@boostpro.com> wrote:
On Tue, Dec 14, 2010 at 9:20 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained"
I'd much rather see maintenership of these libraries transferred to new people, just to avoid fragmentation.
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D -- Dean Michael Berris deanberris.com
On Dec 15, 2010, at 6:48 PM, Dean Michael Berris wrote:
On Thu, Dec 16, 2010 at 2:33 AM, Dave Abrahams <dave@boostpro.com> wrote:
On Tue, Dec 14, 2010 at 9:20 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained"
I'd much rather see maintenership of these libraries transferred to new people, just to avoid fragmentation.
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D
I didn't have any trouble "taking over" Boost.Array. I asked around, no one had any problems with it, and it was done. -- Marshall
On Thu, Dec 16, 2010 at 11:17 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 15, 2010, at 6:48 PM, Dean Michael Berris wrote:
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D
I didn't have any trouble "taking over" Boost.Array. I asked around, no one had any problems with it, and it was done.
Sure, but you did have to get the OK from the original maintainer right? I just wish more people stepped up to do the same for other popular libraries that get used but aren't actively maintained. Note that my definition of actively maintained has something to do with the amount of unresolved issues over time on Trac. Actually, now, I wish there was really a guild I can participate in to "level up" my Boost contribution-fu. ;) -- Dean Michael Berris deanberris.com
I just wish more people stepped up to do the same for other popular libraries that get used but aren't actively maintained. Note that my definition of actively maintained has something to do with the amount of unresolved issues over time on Trac.
OK, lets get specific... care to name names? How about providing patches/fixes for unresolved issues? If it looks like you're doing a good enough job with those, I would expect you to be "volunteered" to take over anyway ;-) John.
On Thu, Dec 16, 2010 at 6:16 PM, John Maddock <boost.regex@virgin.net> wrote:
I just wish more people stepped up to do the same for other popular libraries that get used but aren't actively maintained. Note that my definition of actively maintained has something to do with the amount of unresolved issues over time on Trac.
OK, lets get specific... care to name names?
Ha! :D I knew this was coming at some point in this discussion. I don't know the names of all the maintainers, but the thing I can do is point out some libraries that need some of the love. From the top of my head, there are a number of patches that I've submitted already, which haven't quite made it to any Boost release as far as I know (some of which have been dated to like a year or so already). These libraries I see are: - Boost.Pool - Boost.Optional I think there were some patches that I saw in Boost.Array (not by me) that have already been applied and that's largely because Marshall has done a good job going over the tickets on that library. I remember Boost.Circular_buffer and some other patches to Boost.Serialization that I sent in a while ago to address some issues but haven't been cleared. I know someone has been responding to questions on Boost.Circular_buffer recently so that may have changed. Boost.Serialization I know is a big piece of code and has other issues that may be considered more critical than the ones I've tried to address (recently and in the past).
How about providing patches/fixes for unresolved issues?
I do my best when time permits. ;)
If it looks like you're doing a good enough job with those, I would expect you to be "volunteered" to take over anyway ;-)
Yeah, in which case I don't think *I'm* doing enough in that front. :) -- Dean Michael Berris deanberris.com
OK, lets get specific... care to name names?
Ha! :D I knew this was coming at some point in this discussion.
I don't know the names of all the maintainers, but the thing I can do is point out some libraries that need some of the love. From the top of my head, there are a number of patches that I've submitted already, which haven't quite made it to any Boost release as far as I know (some of which have been dated to like a year or so already). These libraries I see are:
- Boost.Pool - Boost.Optional
I don't know about optional, but Boost.Pool's author hasn't been around in a *long* time: actually it probably doesn't need much in the way of ongoing maintenance, but a facelift would surely be in order!
Yeah, in which case I don't think *I'm* doing enough in that front. :)
Or we've all been too busy to notice :-0 Cheers, John.
On 16/12/10 03:26, Dean Michael Berris wrote:
On Thu, Dec 16, 2010 at 11:17 AM, Marshall Clow<mclow.lists@gmail.com> wrote:
On Dec 15, 2010, at 6:48 PM, Dean Michael Berris wrote:
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D
I didn't have any trouble "taking over" Boost.Array. I asked around, no one had any problems with it, and it was done.
Sure, but you did have to get the OK from the original maintainer right?
Is it a requirement to receive a Go from an original author? I thought there is a mechanism in Boost that grants the Community permission to make decisions if an author/maintainer disappears without any contact. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
----- Original Message ----
From: Mateusz Loskot <mateusz@loskot.net> To: boost@lists.boost.org Sent: Thu, December 16, 2010 10:17:34 AM Subject: Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
On 16/12/10 03:26, Dean Michael Berris wrote:
On Thu, Dec 16, 2010 at 11:17 AM, Marshall Clow<mclow.lists@gmail.com> wrote:
On Dec 15, 2010, at 6:48 PM, Dean Michael Berris wrote:
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D
I didn't have any trouble "taking over" Boost.Array. I asked around, no one had any problems with it, and it was done.
Sure, but you did have to get the OK from the original maintainer right?
Is it a requirement to receive a Go from an original author? I thought there is a mechanism in Boost that grants the Community permission to make decisions if an author/maintainer disappears without any contact.
Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org _______________________________________________
I really shouldn't get involved in this but... You need to move away from the idea of code ownership, especially in the context of a community project. In a way it is a nonsense to require permission of the maintainer. The maintainer is more like a moderator that an owner. In a professional context if someone does not have time to work on a piece of code or leaves the company then whoever needs to make a change to it makes it. Its better to be more agile still and say its always the person who needs to make the change that makes it. The maintainers role is review and accept or reject patches. If the maintainer disappears then the responsibility for review falls to the wider community looking out for and or using that package. With something like boost with strong review processes that should be relatively straight forward. For other projects, if the source code repository is inaccessible or your change is rejected but you believe strongly it should be included and cannot persaude anyone even after review then you can fork but you'll have to take the hit of doing all that maintenance work yourself if you want anyone else but yourself or your team to use your project. Regards, Bruce.
BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device] -- On Dec 16, 2010, at 6:04 AM, Bruce Adams <tortoise_74@yahoo.co.uk> wrote:
You need to move away from the idea of code ownership, especially in the context of a community project. In a way it is a nonsense to require permission of the maintainer. The maintainer is more like a moderator that an owner. In a professional context if someone does not have time to work on a piece of code or leaves the company then whoever needs to make a change to it makes it. Its better to be more agile still and say its always the person who needs to make the change that makes it. The maintainers role is review and accept or reject patches. If the maintainer disappears then the responsibility for review falls to the wider community looking out for and or using that package. With something like boost with strong review processes that should be relatively
straight forward. For other projects, if the source code repository is inaccessible or your change is rejected but you believe strongly it should be included and cannot persaude anyone even after review then you can fork but you'll have to take the hit of doing all that maintenance work yourself if you want anyone else but yourself or your team to use your project.
+1 to all that. We try to respect peoples' sense of ownership but ultimately the only ones you need to get permission from are the moderators, and that's only if you want the code in Boost proper, because that's what we do here. For the record, the big effort to track down Bill Kempf about boost.threads was to get his permission to *change the license* on his code. That's a whole other bag of cats
On Thu, Dec 16, 2010 at 7:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device]
I'm assuming this is an iPhone. ;)
--
On Dec 16, 2010, at 6:04 AM, Bruce Adams <tortoise_74@yahoo.co.uk> wrote:
[snip]
+1 to all that. We try to respect peoples' sense of ownership but ultimately the only ones you need to get permission from are the moderators, and that's only if you want the code in Boost proper, because that's what we do here.
Interesting. So if I wanted to get SVN access and start working on things in a private branch on the Boost SVN repository (for example, to address a specific set of issues against a library Boost.X) and then ask for a code review of the patch I'm potentially going to merge to trunk at some point later, there's a process to do that?
For the record, the big effort to track down Bill Kempf about boost.threads was to get his permission to *change the license* on his code. That's a whole other bag of cats
Ah, alright. Thanks for the clarification on that. So given that a library is under the BSL, and in the Boost repository, what is the process (now) to allow people to work directly on the main-line of a library and start fixing issues? Is submitting tickets to Trac with patches the only way to go about it? How about enabling private branches, and having maintainers merge changes from specific private branches as soon as a code review on the changes on the private branch has been done? I really am eager to know what the definitive answer to this is so that us who really want to contribute to Boost have a clear understanding of what it means to: 1) be a maintainer 2) get access to the repository for commit access and 3) what the expectation is on contributions and contributors alike. I guess this is the point where there has to be a consensus on what the community really wants for the Boost contribution process to be like. Thanks for taking the time to clear things up. Hopefully something comes out of this thread in the form of "community policy" that members of the community can agree upon. -- Dean Michael Berris deanberris.com
On 12/16/10, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Thu, Dec 16, 2010 at 7:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device]
I'm assuming this is an iPhone. ;)
'Fraid it was, yes.
On Dec 16, 2010, at 6:04 AM, Bruce Adams <tortoise_74@yahoo.co.uk> wrote:
[snip]
+1 to all that. We try to respect peoples' sense of ownership but ultimately the only ones you need to get permission from are the moderators, and that's only if you want the code in Boost proper, because that's what we do here.
Interesting. So if I wanted to get SVN access and start working on things in a private branch on the Boost SVN repository (for example, to address a specific set of issues against a library Boost.X) and then ask for a code review of the patch I'm potentially going to merge to trunk at some point later, there's a process to do that?
No, but it doesn't mean we can't do it. It just hadn't come up, yet, so we never set up a process.
For the record, the big effort to track down Bill Kempf about boost.threads was to get his permission to *change the license* on his code. That's a whole other bag of cats
Ah, alright. Thanks for the clarification on that.
So given that a library is under the BSL, and in the Boost repository, what is the process (now) to allow people to work directly on the main-line of a library and start fixing issues? Is submitting tickets to Trac with patches the only way to go about it?
That's all we've got set up ATM, but that doesn't mean anything about what's possible.
How about enabling private branches, and having maintainers merge changes from specific private branches as soon as a code review on the changes on the private branch has been done?
Sounds okay to me; I don't know what the technical/administrative hurdles might be to doing that through SVNManager, but it could get done.
I really am eager to know what the definitive answer to this is so that us who really want to contribute to Boost have a clear understanding of what it means to: 1) be a maintainer 2) get access to the repository for commit access and 3) what the expectation is on contributions and contributors alike. I guess this is the point where there has to be a consensus on what the community really wants for the Boost contribution process to be like.
How about you make a proposal?
Thanks for taking the time to clear things up. Hopefully something comes out of this thread in the form of "community policy" that members of the community can agree upon.
That would be awesome. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Interesting. So if I wanted to get SVN access and start working on things in a private branch on the Boost SVN repository (for example, to address a specific set of issues against a library Boost.X) and then ask for a code review of the patch I'm potentially going to merge to trunk at some point later, there's a process to do that?
It depends - if the library has an active maintainer, then yes, you just ask the maintainer or file a ticket - in that case the easier you can make it for him/her to review the changes the better your chances of getting it through quickly. Otherwise what tends to happen, is some other interested library author, or bug-sprint member, will take on the responsibility for shepherding those changes through. I accept that there may be an issue with there not being enough folks for the above to work all that well though. The basic problem is that to maintain quality we've generally required all library maintainers to already have one accepted Boost library, so I guess the question we're struggling with is how to broaden the field without risking screwing things up too badly :-0 Thinking out loud here... one option might be for someone to say "I'm going to try and give library X a decent update" and solicit the mailing list for bug/feature requests, then carry out the work in the sandbox and ask for a mini-review - at which point you're sort of lumbered with being the new maintainer ;-) HTH, John.
On 1:59 PM, John Maddock wrote:
Interesting. So if I wanted to get SVN access and start working on things in a private branch [...]
It depends - if the library has an active maintainer, then yes, you just ask the maintainer or file a ticket [...]
I accept that there may be an issue with there not being enough folks for the above to work all that well though. The basic problem is that to maintain quality we've generally required all library maintainers to already have one accepted Boost library, so I guess the question we're struggling with is how to broaden the field without risking screwing things up too badly :-0
The crux of Boost.Guild's debate. And so many topics touch on this. So how would you measure, or design a test, to determine how badly things would get screwed up under various scenarios?
Thinking out loud here... one option might be for someone to say "I'm going to try and give library X a decent update" and solicit the mailing list for bug/feature requests, then carry out the work in the sandbox and ask for a mini-review - at which point you're sort of lumbered with being the new maintainer ;-)
If someone is that motivated. But could something useful happen if ten people, each 1/10th as motivated, were to apply themselves?
WARNING: This is a long post. The tl;dr version is: 1) follow the Linux Kernel development model 2) Employ the web of trust system using GPG keys 3) we need a Boost Foundation like the Linux Foundation 4) we need to lower the barrier to entry for would-be contributors 5) use Git/Mercurial for distributed development. On Fri, Dec 17, 2010 at 11:23 PM, Jim Bell <Jim@jc-bell.com> wrote:
On 1:59 PM, John Maddock wrote:
Interesting. So if I wanted to get SVN access and start working on things in a private branch [...]
It depends - if the library has an active maintainer, then yes, you just ask the maintainer or file a ticket [...]
I accept that there may be an issue with there not being enough folks for the above to work all that well though. The basic problem is that to maintain quality we've generally required all library maintainers to already have one accepted Boost library, so I guess the question we're struggling with is how to broaden the field without risking screwing things up too badly :-0
The crux of Boost.Guild's debate. And so many topics touch on this.
So how would you measure, or design a test, to determine how badly things would get screwed up under various scenarios?
I think we need to look outside the box for a solution to this. Let me cite an example of a way to broaden the contributor pool without bogging the release process or the development cycles of developers down. The most successful example of a large open source project that has tons of contributors and has an active community is the Linux Kernel project. There you have Linus, the BDFL of the project, choosing to trust maintainers to make choices regarding the maintenance and improvement of different subsystems. Anybody -- as in absolutely *anybody* -- is encouraged to clone the repository, make their changes, and submit these changes to the maintainer(s) actively maintaining that part of the kernel. You will find that there are different kernels released by different maintainers, but the "de facto" kernel is the one that Linus releases. Note that Linus doesn't check each and every line of code that comes into the kernel. What happens is he trusts a number of maintainers to do that for the subsystems that they're responsible for. This "inner circle" is a smallish group, around 10ish, who then delegate their overall responsibility across a wider number of subsystem maintainers. For your code to get to the "main line" kernel, you'd typically have to submit it to the maintainer of the module you're patching, who then shepherds it in by signing it and merging it into this repository and then asks the maintainer of the subsystem that his module is part of to pull from him, and then later on these maintainers ask Linus to pull from their repositories when it comes time to stabilize and go through the release process. This sounds like a slow process, but because of the decentralized nature of the development of the kernel you have people who have different timelines and pace working on different parts of the kernel without any one thing bogging the work down. The release process does a code/feature freeze but that means the higher up maintainers focus on stabilizing the code and then doing a release -- you can keep working on your repository and changing whatever you want and then when you feel your work is worth pulling in, you ask someone else to pull from you. This model allows for faster innovation, greater involvement, and lower barrier to entry. Now, that doesn't remove the maintainer dilemma -- but the beauty of that system is, even when a maintainer of a subsystem suddenly goes MIA, the community can decide to just pull from a different person's repository. Then, being a maintainer of a subsystem becomes no longer a choice of the original maintainers, but mostly the contributors. Let me try and explain a little bit more. If I'm a developer A, and there's a maintainer B who's supposed to be handling the module X, all I do is clone B's repository locally, make my changes, and then ask maintainer B to pull my changes. I can send him the changes via email, I can post the changes publicly (and sign it with my GPG key), or I can expose my repository publicly so that anybody (not just B) can get it. That should be simple enough to understand. What happens when B goes MIA or unresponsive? That's simple, I ask someone else -- maybe Linus, or maybe some other higher-level maintainer, or just someone the community already trusts -- to pull my changes in. Losing maintainer B is not a hindrance anymore because the community can start pulling from each other and stamping their trust and confidence on the code. Later on the community just elects by way of pull requests who it trusts to be a maintainer of a subsystem. This sounds like some pie-in-the-sky dream, but this is the reality already with the Linux kernel development. It is the single project I know that spans the globe with thousands of contributors. This model is already proven to scale. How does the trust system work? The Linux development team uses GPG heavily -- your key needs to have been signed by others already, and the people that signed your key must be trust worthy (meaning their key has already been signed as well by other trust-worthy people, etc.). So for your key to be signed by Linus Torvalds means something -- this means he trusts that you are someone that he will vouch for in terms of your credibility or "realness". That web of trust keeps people honest because if you start crewing up or doing something bad by community standards, people can revoke their signature on your key and that's like a no vote in parliament. There are a lot of lessons in the Linux kernel development process that Boost can certainly learn from. One of them is to decentralize the development and just maintain a "canonical" or "official" release of the library. Then having people maintaining either ports of the library to different architectures, or having people concentrating on warnings removal, and employing the web of trust system should ensure the sustainability and scalability of the development process. Essentially, by encouraging people to fork and innovate, then later on have their fork folded into the main line is a good and scalable way of developing systems in a progressive manner. Then the release process would just be a matter of the BDFL or the community-trusted people to pull from the maintainers and stabilize to get a suitable release out. What the Linux kernel project has that Boost doesn't (yet) is a Linux Foundation which actually funds the development effort of the kernel. The Linux Foundation ensures that people who want to do the kernel development full-time (like Linus and others like him) get compensated to do the shepherding and the innovation -- of course there's a process for qualifying for Linux Foundation funding. Note that this is different from the Apache Foundation which has a business-oriented and parliamentary involvement process (which at one time I thought would have been a good model for Boost, but have changed thoughts about since a few conversations I've had at BoostCon 2010). A Boost foundation that has stakeholders funding it to ensure that Boost keeps going as a project and compensate those people who would do this full-time but otherwise can't because of their employment (or lack thereof) would be a Good Thing (TM) IMHO.
Thinking out loud here... one option might be for someone to say "I'm going to try and give library X a decent update" and solicit the mailing list for bug/feature requests, then carry out the work in the sandbox and ask for a mini-review - at which point you're sort of lumbered with being the new maintainer ;-)
If someone is that motivated. But could something useful happen if ten people, each 1/10th as motivated, were to apply themselves?
I think the having to say it to the mailing list part and asking for permission is the wrong way of going about it. I think, if someone wants to do it, they should be able to do it -- and if their code is good and the community (or the people that the community trusts) vote with their pulls, then it gets folded in appropriately. For the matter of having 10 people work on it, I don't think it will change the situation. If we use the current system of the maintainers being the BDFL's for the projects they "maintain" and not allowing anybody else to take the library in a different direction and letting the community have a choice on the matter, is I think, not scalable. I would much rather have 10 implementations of a Bloom filter, let the people choose which one is better, and then have that implementation pulled into the main release. The same goes for all the libraries already in the repository. Just to note, what I'm driving at here is the need to lower the barrier to entry into Boost while having a means of ensuring quality for the "official"/"canonical" Boost release. Right now there are already a handful of release managers who I think don't do the release management on a full-time basis, but could manage just pulling changes from projects that have different development pace than the release process. This requires of course that the libraries be broken up into individual pieces and that the release process would be a stabilization effort rather than an active development effort. The issue of dependency management I think is over-blown with hypothetical situations -- the Linux kernel is one monolithic kernel and the lower-level subsystem details still get changed every so often (things that almost all the other parts depend on -- scheduler, memory management APIs, etc.) and they never had to complicate the matter of dependencies among the parts. Of course, it's needless to say that Boost ought to really go either Git or Mercurial to make doing this kind of distributed development trivial. ;) Have a good one guys and I hope this helps. -- Dean Michael Berris about.me/deanberris
Thanks for your thoughtful reply. On 1:59 PM, Dean Michael Berris wrote:
WARNING: This is a long post. The tl;dr version is: 1) follow the Linux Kernel development model 2) Employ the web of trust system using GPG keys 3) we need a Boost Foundation like the Linux Foundation 4) we need to lower the barrier to entry for would-be contributors 5) use Git/Mercurial for distributed development.
On Fri, Dec 17, 2010 at 11:23 PM, Jim Bell <Jim@jc-bell.com> wrote:
[...] The crux of Boost.Guild's debate. And so many topics touch on this.
So how would you measure, or design a test, to determine how badly things would get screwed up under various scenarios?
[snip excellent but time-consuming ideas...] A Boost foundation that has stakeholders funding it to ensure that Boost keeps going as a project and compensate those people who would do this full-time but otherwise can't because of their employment (or lack thereof) would be a Good Thing (TM) IMHO.
Compensating people would definitely bring a solution. So is the solution to pursue that aggressively? How many FTE's are on staff with Linux? How many would we ask? Does the Linux kernel have metrics? How long does an average change sit in the queue?
Thinking out loud here... one option might be for someone to say "I'm going to try and give library X a decent update" and solicit the mailing list for bug/feature requests, then carry out the work in the sandbox and ask for a mini-review - at which point you're sort of lumbered with being the new maintainer ;-) If someone is that motivated. But could something useful happen if ten people, each 1/10th as motivated, were to apply themselves?
I think the having to say it to the mailing list part and asking for permission is the wrong way of going about it. I think, if someone wants to do it, they should be able to do it -- and if their code is good and the community (or the people that the community trusts) vote with their pulls, then it gets folded in appropriately. For the matter of having 10 people work on it, I don't think it will change the situation.
I'm much less concerned about a library's future direction than I am it's present quality.
If we use the current system of the maintainers being the BDFL's for the projects they "maintain" and not allowing anybody else to take the library in a different direction and letting the community have a choice on the matter, is I think, not scalable. I would much rather have 10 implementations of a Bloom filter, let the people choose which one is better, and then have that implementation pulled into the main release. The same goes for all the libraries already in the repository.
Ten implementations makes everyone spend time deciding on which to adopt, and multiplies the MIA maintainer problem. (Will my choice's maintainer go MIA? How do I know?) A peer-reviewed best helps me more as a user.
On Sun, Dec 19, 2010 at 12:26 AM, Jim Bell <Jim@jc-bell.com> wrote:
Thanks for your thoughtful reply.
You're welcome, I do my best. :)
On 1:59 PM, Dean Michael Berris wrote:
WARNING: This is a long post. The tl;dr version is: 1) follow the Linux Kernel development model 2) Employ the web of trust system using GPG keys 3) we need a Boost Foundation like the Linux Foundation 4) we need to lower the barrier to entry for would-be contributors 5) use Git/Mercurial for distributed development.
On Fri, Dec 17, 2010 at 11:23 PM, Jim Bell <Jim@jc-bell.com> wrote:
[...] The crux of Boost.Guild's debate. And so many topics touch on this.
So how would you measure, or design a test, to determine how badly things would get screwed up under various scenarios?
[snip excellent but time-consuming ideas...]
:)
A Boost foundation that has stakeholders funding it to ensure that Boost keeps going as a project and compensate those people who would do this full-time but otherwise can't because of their employment (or lack thereof) would be a Good Thing (TM) IMHO.
Compensating people would definitely bring a solution. So is the solution to pursue that aggressively? How many FTE's are on staff with Linux? How many would we ask?
I'm not sure about the Linux foundation, but as far as I know this information is public. Just like any non-profit, that information should be easy to come by as they have to disclose their operational details appropriately. A quick look at the website says there are a number of fellows and board members.
Does the Linux kernel have metrics? How long does an average change sit in the queue?
Yes, and the (good) changes, depending on whether you get community approval never sits longer than 2 weeks -- last I checked. This means, your changes usually get upstream really quick especially if it's within the active development window and the community likes what you've done. The code review actively happens on the mailing list, which is the central hub of the changes. Larger projects though typically take a lot of time because they get broken up into smaller chunks that get introduced into the kernel pieces at a time over a number of releases -- this is the way they deal with eventually breaking changes in the API or the internals; it allows other developers to migrate their code that depends on the old API into the new API over a period of time.
Thinking out loud here... one option might be for someone to say "I'm going to try and give library X a decent update" and solicit the mailing list for bug/feature requests, then carry out the work in the sandbox and ask for a mini-review - at which point you're sort of lumbered with being the new maintainer ;-) If someone is that motivated. But could something useful happen if ten people, each 1/10th as motivated, were to apply themselves?
I think the having to say it to the mailing list part and asking for permission is the wrong way of going about it. I think, if someone wants to do it, they should be able to do it -- and if their code is good and the community (or the people that the community trusts) vote with their pulls, then it gets folded in appropriately. For the matter of having 10 people work on it, I don't think it will change the situation.
I'm much less concerned about a library's future direction than I am it's present quality.
But improving the quality (or maintaining it at least) *is* future direction of a library. "Staying put" is a direction too (or lack thereof, depends on how you look at time. :D).
If we use the current system of the maintainers being the BDFL's for the projects they "maintain" and not allowing anybody else to take the library in a different direction and letting the community have a choice on the matter, is I think, not scalable. I would much rather have 10 implementations of a Bloom filter, let the people choose which one is better, and then have that implementation pulled into the main release. The same goes for all the libraries already in the repository.
Ten implementations makes everyone spend time deciding on which to adopt, and multiplies the MIA maintainer problem. (Will my choice's maintainer go MIA? How do I know?) A peer-reviewed best helps me more as a user.
No, actually, your maintainers still choose which ones to bake into the official release. This just means that the choice of which one is a community-wide decision, which the maintainers would just grant. Let me try to explain. For example, someone else wants to work on a competing cpp-netlib implementation that wants to make it into Boost. The current process means that that person would have to do all the work outside of Boost, submit it for review, have that review scheduled, and wait until the review finishes and the review manager announces whether the library is accepted or rejected. Now in the process I'm proposing (which mirrors the Linux Kernel development effort), anybody can absolutely just clone the Boost libraries he's depending on, keep working on the implementation and involve the whole Boost community in the effort if there's enough interest. Now which version of the network library gets accepted is just a matter of people voting by expressing their interest into which implementation they want pulled into Boost -- this can happen anytime, and can even be a prolonged process instead of just a week of reviews. This on-going review process allows people to collaboratively develop a library that eventually gets into Boost when it's mature enough to be taken into the main Boost distribution. This way, it's still peer-reviewed, and the review is an on-going process. It's a lot more fluid, and the barrier to entry is significantly lower. This also means who the maintainers are would be a matter of election and expression of trust -- which means, for example, I definitely would trust someone like Marshall Clow and Steven Watanabe to be a maintainer of something like a Netlib implementation in Boost. For example, I as the main developer of cpp-netlib along with other developers who already are credited in the implementation can continue as developers pushing the boundaries for example instead of being bogged down by being just a maintainer of the library. This turns the process upside-down -- anybody can then write a library and get it up to Boost-level standards, and people who want to contribute can contribute in a purely meritocratic environment. That means if your code is good, your code gets in -- more code you have in the project, the more trust you gain from other contributors. Then when it seems official Boost-level implementation/design, then the community can vote it in to be included into the main Boost distribution. This also then allows people to have roles such as support engineers who patch officially released code. Some people -- like me -- like living on the bleeding edge and pushing the boundaries of what's possible in a library. Others like to keep things stable and contribute to fixing issues that appear in releases. This now means Boost can have a major release number and have people keep contributing to the version 2 line and keep the interfaces stable -- everybody who likes to push the boundaries can work on the next version. Some people might even want to keep supporting major Boost version releases for a longer period of time -- this way there's more opportunities for people to contribute. I hope that makes sense, and if in case it's not clear yet, I can elaborate on it more -- most probably when I get to my final destination as I'm writing this in the Hong Kong International Airport, en route to Sydney, Australia. :D Have a good one and I hope this helps! -- Dean Michael Berris about.me/deanberris
At Sat, 18 Dec 2010 14:00:09 +0800, Dean Michael Berris wrote:
WARNING: This is a long post. The tl;dr version is: 1) follow the Linux Kernel development model 2) Employ the web of trust system using GPG keys 3) we need a Boost Foundation like the Linux Foundation 4) we need to lower the barrier to entry for would-be contributors 5) use Git/Mercurial for distributed development.
Now, that doesn't remove the maintainer dilemma -- but the beauty of that system is, even when a maintainer of a subsystem suddenly goes MIA, the community can decide to just pull from a different person's repository. Then, being a maintainer of a subsystem becomes no longer a choice of the original maintainers, but mostly the contributors. Let me try and explain a little bit more.
If I'm a developer A, and there's a maintainer B who's supposed to be handling the module X, all I do is clone B's repository locally, make my changes, and then ask maintainer B to pull my changes. I can send him the changes via email, I can post the changes publicly (and sign it with my GPG key), or I can expose my repository publicly so that anybody (not just B) can get it. That should be simple enough to understand.
What happens when B goes MIA or unresponsive? That's simple, I ask someone else -- maybe Linus, or maybe some other higher-level maintainer, or just someone the community already trusts -- to pull my changes in. Losing maintainer B is not a hindrance anymore because the community can start pulling from each other and stamping their trust and confidence on the code. Later on the community just elects by way of pull requests who it trusts to be a maintainer of a subsystem.
This sounds like some pie-in-the-sky dream, but this is the reality already with the Linux kernel development. It is the single project I know that spans the globe with thousands of contributors. This model is already proven to scale.
One problem I see coming is that we have a very simple two-level hierarchy: there are library maintainers and release managers. There's nobody at an intermediate level who's responsible for a large group of libraries that would correspond to a Linux "subsystem." Not insurmountable, but we'd need to invent a structure for it.
A Boost foundation that has stakeholders funding it to ensure that Boost keeps going as a project and compensate those people who would do this full-time but otherwise can't because of their employment (or lack thereof) would be a Good Thing (TM) IMHO.
Interesting thought. What stakeholders do you think would be willing to provide funding?
Thinking out loud here... one option might be for someone to say "I'm going to try and give library X a decent update" and solicit the mailing list for bug/feature requests, then carry out the work in the sandbox and ask for a mini-review - at which point you're sort of lumbered with being the new maintainer ;-)
If someone is that motivated. But could something useful happen if ten people, each 1/10th as motivated, were to apply themselves?
I think the having to say it to the mailing list part and asking for permission is the wrong way of going about it. I think, if someone wants to do it, they should be able to do it -- and if their code is good and the community (or the people that the community trusts) vote with their pulls, then it gets folded in appropriately. For the matter of having 10 people work on it, I don't think it will change the situation.
+1 -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sun, Dec 19, 2010 at 4:39 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Sat, 18 Dec 2010 14:00:09 +0800, Dean Michael Berris wrote:
WARNING: This is a long post. The tl;dr version is: 1) follow the Linux Kernel development model 2) Employ the web of trust system using GPG keys 3) we need a Boost Foundation like the Linux Foundation 4) we need to lower the barrier to entry for would-be contributors 5) use Git/Mercurial for distributed development.
Now, that doesn't remove the maintainer dilemma -- but the beauty of that system is, even when a maintainer of a subsystem suddenly goes MIA, the community can decide to just pull from a different person's repository. Then, being a maintainer of a subsystem becomes no longer a choice of the original maintainers, but mostly the contributors. Let me try and explain a little bit more.
If I'm a developer A, and there's a maintainer B who's supposed to be handling the module X, all I do is clone B's repository locally, make my changes, and then ask maintainer B to pull my changes. I can send him the changes via email, I can post the changes publicly (and sign it with my GPG key), or I can expose my repository publicly so that anybody (not just B) can get it. That should be simple enough to understand.
What happens when B goes MIA or unresponsive? That's simple, I ask someone else -- maybe Linus, or maybe some other higher-level maintainer, or just someone the community already trusts -- to pull my changes in. Losing maintainer B is not a hindrance anymore because the community can start pulling from each other and stamping their trust and confidence on the code. Later on the community just elects by way of pull requests who it trusts to be a maintainer of a subsystem.
This sounds like some pie-in-the-sky dream, but this is the reality already with the Linux kernel development. It is the single project I know that spans the globe with thousands of contributors. This model is already proven to scale.
One problem I see coming is that we have a very simple two-level hierarchy: there are library maintainers and release managers. There's nobody at an intermediate level who's responsible for a large group of libraries that would correspond to a Linux "subsystem." Not insurmountable, but we'd need to invent a structure for it.
Yep. And there would basically have to be either one, or a set of people who act as the BDFLs. In the end the hierarchy allows the structure to scale in a non-linear fashion without significantly bogging down the whole process.
A Boost foundation that has stakeholders funding it to ensure that Boost keeps going as a project and compensate those people who would do this full-time but otherwise can't because of their employment (or lack thereof) would be a Good Thing (TM) IMHO.
Interesting thought. What stakeholders do you think would be willing to provide funding?
Off the top of my head, commercial interest would mostly come from the bigger users of Boost -- last I checked those would be the likes of Adobe, Facebook (?), maybe Google (?). Also the Linux Foundation is structured in a way that allows anybody -- big and small -- to sponsor the development of a particular part of the library or particular fellows. Thinking about it a little more, even those commercial interests outside of the US might be willing to contribute. Just getting feedback from the people using Boost would be a good thing to do if anybody else is willing to pursue this direction. HTH :) -- Dean Michael Berris about.me/deanberris
Dave Abrahams <dave <at> boostpro.com> writes:
Interesting thought. What stakeholders do you think would be willing to provide funding?
As a first try we could ask for donation, the same way Wikipedia does. There is a wonderful thing in corporations, called "matching gift": http://wikimediafoundation.org/wiki/Donate/Match_Your_Gift/en See how long is the list, and I believe it's far from complete. This basically means that programmers from these corporations (users of Boost, basically) can make monetary gifts (up to certain amount per year) to a on-profit Boost Foundation, then corporations will just reimburse the gift to them. IANAL, but to me it looks like the programmers can donate to Boost for free using this sceme. Thanks, Maxim
Scott McMurray <me22.ca+boost <at> gmail.com> writes:
IANAL, but to me it looks like the programmers can donate to Boost for free using this sceme.
The match goes to the non-profit, not to the employee, so no, it's not free for the employee.
Oh... Looks like I missed the point completely and won't get my money back :)
On 16/12/10 11:04, Bruce Adams wrote:
----- Original Message ----
From: Mateusz Loskot<mateusz@loskot.net> To: boost@lists.boost.org Sent: Thu, December 16, 2010 10:17:34 AM Subject: Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
On 16/12/10 03:26, Dean Michael Berris wrote:
On Thu, Dec 16, 2010 at 11:17 AM, Marshall Clow<mclow.lists@gmail.com> wrote:
On Dec 15, 2010, at 6:48 PM, Dean Michael Berris wrote:
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D
I didn't have any trouble "taking over" Boost.Array. I asked around, no one had any problems with it, and it was done.
Sure, but you did have to get the OK from the original maintainer right?
Is it a requirement to receive a Go from an original author? I thought there is a mechanism in Boost that grants the Community permission to make decisions if an author/maintainer disappears without any contact.
I really shouldn't get involved in this but... You need to move away from the idea of code ownership, especially in the context of a community project.
In spite of the fact you followed up my post, I assume you don't address the "You need to" directly to me but to the Community in general.
In a way it is a nonsense to require permission of the maintainer. [...]
All you've written sounds somewhat obvious to me, indeed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On Thu, Dec 16, 2010 at 7:32 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 16/12/10 11:04, Bruce Adams wrote:
I really shouldn't get involved in this but... You need to move away from the idea of code ownership, especially in the context of a community project.
In spite of the fact you followed up my post, I assume you don't address the "You need to" directly to me but to the Community in general.
Either he meant "You" as in the Community, or "You" as in "Dean Michael Berris" (or in this case, me :D ).
In a way it is a nonsense to require permission of the maintainer.
[...]
All you've written sounds somewhat obvious to me, indeed.
Yeah, but what is the current process reflecting? Because the maintainer essentially has a say on: 1. What code goes in. 2. When the changes get to the release branch. 3. Who gets commit access to the repository and is able to make that person a co-maintainer. Really, it looks like every action a contributor would make would require the approval of the maintainer. Private branches might be a good option, but then I'm not sure what the policy is (or what the permission model in the current SVN set up is like) is on granting private branch privileges to people -- I'm also not sure if the infrastructure as it currently is makes this private branching sustainable for a wide number of contributors. So in the end, in the context of Boost, it seems the only "effective" way of being able to contribute more than just the occasional patches to a library through Trac is to be a co-maintainer of a library. Then you run into the issue of what happens when the maintainer doesn't like^H^H^H^H know you or doesn't have time to make you a co-maintainer of the library? I guess I'm looking at things wrong and if I am I would really be appreciative if someone can correct my interpretation of the situation. -- Dean Michael Berris deanberris.com
On 16/12/10 12:04, Dean Michael Berris wrote:
On Thu, Dec 16, 2010 at 7:32 PM, Mateusz Loskot<mateusz@loskot.net> wrote:
On 16/12/10 11:04, Bruce Adams wrote:
I really shouldn't get involved in this but... You need to move away from the idea of code ownership, especially in the context of a community project.
In spite of the fact you followed up my post, I assume you don't address the "You need to" directly to me but to the Community in general.
Either he meant "You" as in the Community, or "You" as in "Dean Michael Berris" (or in this case, me :D ).
Based on the chronology and posts sequence, I still claim some rights to the title of "You" ,-)
In a way it is a nonsense to require permission of the maintainer.
[...]
All you've written sounds somewhat obvious to me, indeed.
Yeah, but what is the current process reflecting? [...]
That's what I've asked about. Currently, the maintainer's responsibilities [1] are concluded with "If at some point you no longer wish to serve as maintainer of your library, it is your responsibility to make this known to the boost community and to find another individual to take your place." [1] http://www.boost.org/community/reviews.html Perhaps they should be updated with what Bruce has expalined and Dave agreed with. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
----- Original Message ----
From: Mateusz Loskot <mateusz@loskot.net> To: boost@lists.boost.org Sent: Thu, December 16, 2010 1:08:03 PM Subject: Re: [boost] [OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
On 16/12/10 12:04, Dean Michael Berris wrote:
On Thu, Dec 16, 2010 at 7:32 PM, Mateusz Loskot<mateusz@loskot.net> wrote:
On 16/12/10 11:04, Bruce Adams wrote:
I really shouldn't get involved in this but... You need to move away from the idea of code ownership, especially in the context of a community project.
In spite of the fact you followed up my post, I assume you don't address the "You need to" directly to me but to the Community in general.
Either he meant "You" as in the Community, or "You" as in "Dean Michael Berris" (or in this case, me :D ).
Based on the chronology and posts sequence, I still claim some rights to the title of "You" ,-)
I knew I should have stayed out of this :) I meant "you" as in the "community" and I meant "should consider" rather than "need". Its not an order or a criticism just an observation that it seems to work better than way in my experience.
In a way it is a nonsense to require permission of the maintainer.
[...]
All you've written sounds somewhat obvious to me, indeed.
Good. That means I'm not talking complete garbage. Still you probably wouldn't be amazed at how what is blindingly obvious to one person is clear as mud to another.
Yeah, but what is the current process reflecting? [...]
That's what I've asked about.
Currently, the maintainer's responsibilities [1] are concluded with
"If at some point you no longer wish to serve as maintainer of your library, it is your responsibility to make this known to the boost community and to find another individual to take your place."
[1] http://www.boost.org/community/reviews.html
Perhaps they should be updated with what Bruce has expalined and Dave agreed with.
I'm an outsider with no say in the matter and no experience with submitting patches to boost. I would have thought that if someone has been trusted enough to have access to SVN to include their own contributions they can be trusted to access the rest of the source tree. Anyone who abused that priviledge would see it rapidly withdrawn. One point of source control is that you can roll back if things go awry. Regards, Bruce.
On Dec 15, 2010, at 7:26 PM, Dean Michael Berris wrote:
On Thu, Dec 16, 2010 at 11:17 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 15, 2010, at 6:48 PM, Dean Michael Berris wrote:
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D
I didn't have any trouble "taking over" Boost.Array. I asked around, no one had any problems with it, and it was done.
Sure, but you did have to get the OK from the original maintainer right?
I did. However, in my case this was not a problem. I just asked, and Nicolai said "Sure".
I just wish more people stepped up to do the same for other popular libraries that get used but aren't actively maintained. Note that my definition of actively maintained has something to do with the amount of unresolved issues over time on Trac.
Actually, now, I wish there was really a guild I can participate in to "level up" my Boost contribution-fu. ;)
Sounds like that's going to happen. ;-) -- Marshall
I agree with you, but getting the current maintainers -- who are technically, not maintaining the libraries -- to yield maintenance at least to the whole community (or to a larger set of contributors) hasn't been "proven" yet at least for Boost. I know Boost.Thread had been taken over successfully before, that precedent required having to track down the (sole) original maintainer, getting him to agree and yield to a specific person, sounds like a lot of work compared to just people clicking a button to "fork". :D
Boost.Thread was only complicated because of license issues, for a library that's under the BSL, the original maintainer can hardly complain if someone takes it over (with the consent of the mailing list) while they're AWOL. Just my 2c... John.
participants (11)
-
Bruce Adams -
Dave Abrahams -
Dean Michael Berris -
Jim Bell -
John Maddock -
Jonathan Franklin -
Marshall Clow -
Mateusz Loskot -
Maxim Yanchenko -
mloskot
-
Scott McMurray