On 15/10/15 00:53, Hunter Poe wrote: > 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. It is perfectly possible to resolve problems without rewriting from scratch. Sometimes we need to rewrite a subsystem. Documentation does not automatically come with a new design, and many problems can be solved by incremental refactoring.
One big problem at the moment is lack of review capacity: Rewrite a whole subsystem and it may take a year to get merged because the release manager doesn't have time to review it. This happened with my rewrite of the client layer last year. This is an area where paid staff could be really helpful (although obviously that shouldn't be their sole role). As for the rest, IMHO a lot of it is simply because Freenet is an open source project, which hasn't reached the critical mass - and in fact never will - that Linux, Apache, Bitcoin, LibreOffice and Firefox have reached. In most of these cases there are major corporations contributing full-time developers. That will never be the case for Freenet. As for the rest, the internet hype and fundraising machine (Kickstarter, the wider dot com bubble, and the press) is largely around start-ups - profitable businesses. Doing something as a non-profit means we need to be good at fund-raising - either on the micro- level, or on the funding application level.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
