Hi, there
I have been a user of Freenet for several years now, and am at this point still a pretty junior develop, but finally feel my capabilities have advanced to the point where I would feel comfortable starting to do some work with Freenet and contributing my, albeit limited, skills. As consequence of this I have been following the mailing list a little more closely the past week or two and it seems to me that one of the big issues is as Ian pointed out Freenet is rather aged, and so are many of the development methodologies, tools, and libraries, and it appears in consequence of that, as well as several other hurdles, have made it difficult for developers to join in the work. This has resulted in a state where as Ian stated, we are basically running in maintenance mode with a backlog of bugs, and trying to keep things mostly working. Which at least in my limited experience is often one of the less exciting tasks in a developers life. In addition because Freenet has been able to stand so long on its own (15 years is quite the lifetime for an application) but has resulted in numerous patches, and as Brookes points out in the “Mythical Man Month” that when we fix a bug we end up just introducing more bugs that are subtler. It seems to me that the best way to revitalize Freenet would be to re-architect and rebuild Freenet, starting with documenting how Freenet is actually working according to the code. I have found in my rather limited experience that often times when I am forced to verbalize or articulate what my code is doing can sometimes bring epiphanies that help me make major breakthroughs (source: http://story.fund/post/114720918282/debugging-teddy-bea <http://story.fund/post/114720918282/debugging-teddy-bear>r). The Freenet 2.0 as it were could include a modernized build system, if we are concerned about pulling down insecure dependencies we could look at creating our own Freenet specific libraries that although this would cause us to reinvent the wheel in some cases it could also help us reevaluate the need for the specific component reducing software bloat, and give us the guarantee of security. We could also move to a more compartmentalized and separated model for Freenet, separating the deamon, and clients, changing the way we handle plugins. As well as standardizing testing and development procedures. An expanded and more concise documentation and a modernization of build tools could lower the bar for entry for new developers which would in turn cascade into more devs contributing. Ultimately we may need to make sacrifices in philosophical purity, and some compromises on how we want to handle certain aspects of our development or methodology in order to ensure the continued survival of Freenet, because regardless of how secure Freenet is, or how well the source code has been vetted, or how much we trust the repositories we are pulling from. If no one is running it because it has become to kludgy or unwieldy to use or run, we are failing at our fundamental mission of providing secure, anonymous, censorship resistant communication. Like I said I am still a fairly inexperienced and junior developer and could be quite off base, but these are just my thoughts. I think the other option we could do is just send the entire code base and administration and everything else over to the NSA and the FBI and ask them to start maintaining them, I’m sure they would totally dig that. ;) Sincerely, A concerned citizen opposed to a surveillance state. On Wed, Oct 14, 2015 at 5:44 PM Steve Dougherty <st...@asksteved.com> wrote: > On 10/14/2015 03:22 PM, Ian Clarke wrote: > > I think it's time for us all to take a step back and have a serious > > conversation about where we are, and where we are going. > > > > Our current bank account balance is US$1,184.32, our current PayPal > balance > > is $1,201.60. > > > > Even at Xor's very low hourly rate (he could get a lot more commercially > > given his skillset - which we should all appreciate him for) this is less > > than 100 hours of remaining availability. He needs to prepare for > finding > > an alternate income source. > > Agreed. > > > We have a new website in the works, which is great, and many people have > > been working valiantly to support the project, but it's hard to escape > the > > feeling that we're almost in a "maintenance mode". The problem with > that > > is that you just can't generate enough excitement to attract funding in > > that situation. > > It's true that with a small handful of part-time and almost entirely > volunteer developers the project has moved very slowly. I can say that > when I talk with people at cryptoparties about Freenet they are > generally interested, but that has yet to result in anyone contributing > code. In addition to the things you mentioned in "Behind the times," > another thing that doesn't help is messy code keeps some developers from > joining the project, but we'd need developers to clean up the messy > code. Money can help solve that problem but we don't have it. > > I'm looking into holding a Freenet setup hackathon thing in December. > > ... > > Anyway, I don't want to say too much because I'd prefer for this to be > more > > of a conversation than a lecture, but I would appreciate people's > thoughts > > on this. > > Here's what would make sense to me: > > * Stop hiring xor as soon as viable and only pay infrastructure costs: > server, domain name, certificates. How much are those per year? > (amortized for multi-year certs) > * Make a news entry on the website that we can no longer afford to hire > a developer and can be run only by volunteers. Solicit donations, > mention how much infrastructure costs per year, and how much hiring > xor would require in addition. > * Add a useralert in build 1471 that the project is too low on funds to > continue hiring a developer; see the website for details / include > Bitcoin address. (to avoid the added complication of an updatable > useralert.) > * Replace the months of funding bar with dollar amounts and a goal of a > year of infrastructure costs. (maybe? concept would be once that's > met the stretch goal is another year of xor's services.) > > The part that seems non-optimal to me is we've always mentioned the > current funding level, and presented it as something that always goes > down. While that's what it is, it seems more encouraging to raise a > fixed amount that will last for a longer period and stop mentioning it > until it get lows again. > > I think another thing being staffed by volunteers has done is made the > project rather directionless. By their nature volunteers tend to work on > what they find interesting, and it doesn't build toward a focused goal. > Volunteers are great at polishing and adding small things, but usually > can't have the focus and time that paid / full-time developers do to > make large changes. > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
